Vous avez fondamentalement besoin que l'organisation la valorise dans son ensemble.

J'étais avec vous il y a quelques mois. Je fais maintenant partie de ces développeurs qui vous frustrent.

La réalité est que les gens ont certains délais en tête et que ceux-ci ne changent jamais. Vous leur faites une démonstration, puis ils sont "où est-il? Où est-il?" Et ils le feront à chaque fois. Cela s'ajoute aux personnes soucieuses de faire avancer les choses. Les organisations ont également tendance à valoriser certaines choses et ces valeurs déterminent la façon dont les choses sont faites.

La conversation se déroule généralement comme suit:

Personne: "Hé, où est cette fonctionnalité que vous m'avez montrée hier ? "

Moi:" Il attend la révision du code. "

Personne:" Eh bien, nous en avons besoin pour QA / résoudre le problème de production / l'avoir dans la démo du sprint / pour le client réunion de demain "

Moi:" C'est derrière ce que vous m'avez demandé hier dans la file d'attente. "

Personne:" Eh bien, nous en avons besoin pour QA / résoudre le problème de production / l'avoir dans la démo de sprint / pour la réunion client demain "

Moi:" Je vais voir ce qui peut être fait. "

Personne (une heure plus tard):" Des mises à jour? Nous besoin pour QA / résoudre le problème de production / l'avoir dans la démo de sprint / pour la réunion client demain. "

Après des mois et des mois de cela, git push est un diable beaucoup plus facile à faire. D'autant qu'en ce qui les concerne, c'est urgent, donc ils sont très motivés pour l'obtenir. À bien des égards, ils ont raison car les délais sont réels et ne peuvent pas être contrôlés. Donc, même du point de vue d'une unité commerciale, c'est probablement la bonne décision.

Pour que les processus survivent, l'organisation dans son ensemble (ou du moins toute l'unité commerciale) doit les valoriser. Votre organisation ne le fait clairement pas. Cela entraîne-t-il plus de bogues? Probablement. Mais les gens en dehors des logiciels en sont venus à accepter les bogues comme quelque chose qui se produit, donc les prévenir n'est souvent pas la priorité absolue.

C'est une question de compromis, à la fois pour l'organisation et pour les développeurs individuels.

Si vous voulez résoudre ce problème, vous devez essentiellement convaincre les ventes, le Scrum master et le propriétaire du produit qu'il est utile de ne pas contourner ce processus Ils la considèrent probablement comme de la bureaucratie.

Notre patron est d'accord que nous ne devrions pas faire ça, mais il ne veut pas avoir à se battre constamment avec les gens, alors il laisse juste glisser et me dit de dire aux autres développeurs de repousser. 80% du code sort maintenant sans

Il vous demande de faire son travail. Pas du tout professionnel. Cela ne devrait pas être un combat constant. Cela devrait être une loi absolue et les combats cesseraient après une ou deux réprimandes écrites.

Vous ne pouvez vraiment pas faire grand-chose dans cette situation. Vous et les autres développeurs concernés pourriez essayer de faire pression par les pairs, mais il ne semble pas qu'il y ait suffisamment de soins, ou que vous n'avez pas (naturellement) abandonné, pour faire une différence.

honnêtement, commencez à chercher un autre emploi

MODIFIER:

Une autre option, si vous sentez que vous avez tout essayé avec votre patron, serait de passer par-dessus la tête de votre patron à leur patron et chercher à résoudre ce problème plus haut dans la chaîne. Cela devrait être fait avec soin, et peut-être de manière anonyme, car passer la tête de votre patron peut avoir de graves répercussions.

Pour le moment: ne rien faire. Tout va bien, rien n'est cassé.

La prochaine fois qu'un bug de rupture de production se produit: Criez du haut de vos poumons (pas littéralement) sur la façon dont ce bug aurait pu être évité si nous avions eu des tests pour attraper il. Expliquez comment des tests minutieux et prendre du temps visent spécifiquement à éviter ce type de situation. Quantifiez combien d'argent l'entreprise a perdu et combien de temps d'indisponibilité le service a eu à cause d'un bogue qui n'a pas été détecté mais qui aurait pu être si les développeurs avaient eu plus de temps pour être plus prudents.

La gestion est toujours plus ouverte à un changement de processus lorsqu'ils voient la valeur de première main et immédiatement. Si vous parlez dans l'abstrait, comme "eh bien, nous devrions vraiment faire des tests, car un jour nous pourrions avoir un problème quelque part qui pourrait détruire nos serveurs", personne ne s'en soucie, car aussi probablement que cela puisse arriver, cela pourrait également ne pas arriver, et pour l'instant, cela ne se produit pas, donc personne ne s'en soucie. Cependant, cela finira certainement par arriver, et c'est à ce moment-là que vous pourrez le désigner comme un problème et montrer la valeur immédiatement, pas dans l'abstrait.

Bien sûr, la direction pourrait revenir et dire "eh bien, si vous étiez de meilleurs développeurs, vous ne feriez pas de bogues et vous n’auriez pas besoin de tests ». C'est le moment où vous rafraîchissez votre CV et trouvez un autre emploi. Chaque développeur fait des erreurs; il n'y a aucun développeur qui n'ait jamais expédié de code bogué, et il est de la responsabilité de l'entreprise de donner aux développeurs le temps de s'assurer que leur code est aussi exempt de bogues que possible.

Vous avez mal diagnostiqué votre problème.

Que constatez-vous avec le contournement des normes / avis / etc? C'est un symptôme de votre problème.

Votre problème réel est la combinaison de deux choses:

• Votre patron ne veut pas être conflictuel sur les choses
• Vos collègues considèrent le travail comme temporaire et ne font que le minimum

Votre patron a effectivement délégué la confrontation du domaine d'activité à vos collègues ... et vos collègues sont juste suivre le courant jusqu'à ce qu'ils trouvent un autre emploi. Je serais très surpris si les normes en sont le seul symptôme. Vos priorités sont-elles dictées par les cris les plus élevés, et non par ce qui aide le plus l'entreprise? Ce n'est pas un problème distinct de votre question - c'est quelque chose qui aussi découle de ce combo. Etc - il y a probablement des dizaines de problèmes, petits et grands, qui découlent de ces deux facteurs.

En réalité, vous ne pouvez pas résoudre ce problème. Vos meilleurs clichés seraient:

• Faire en sorte que votre patron commence à faire son travail, ou le faire remplacer par quelqu'un qui le fera.
• Rendre l'atmosphère de travail suffisamment agréable pour que vos collègues considéré comme une carrière.

Pour les vendeurs qui ont besoin d'une fonctionnalité dans leur démo, vous pouvez configurer une succursale de démonstration et un serveur de démonstration. Il suffit de pousser tout ce dont ils ont besoin de toute urgence, puis de le fusionner dans la branche dev et éventuellement la branche master une fois les tests unitaires et la révision du code terminés.

Sauter le processus pour obtenir quelque chose avant la fin du sprint ou avant le standup est idiot et les gains à court terme seront compensés par la nécessité de réparer quelque chose en production. Votre équipe doit comprendre la valeur des tests et de la révision du code, et vous devrez peut-être également réviser vos estimations de points d'histoire s'il y a une précipitation pour commettre des choses inachevées avant la fin du sprint.

Dans les cas où des tiers commencent à se mêler de votre processus, arrêtez simplement de leur expliquer votre processus. Chaque extrait d'informations que vous leur donnez leur donne un nouveau crochet pour expliquer pourquoi vous devriez / ne devriez pas faire quelque chose.

Dans une entreprise où le refactoring était constamment ignoré en raison de délais "urgents" (j'utilise des guillemets car tout était toujours la priorité absolue sans exception), j'ai simplement arrêté de mentionner le refactoring comme une étape distincte (et donc individuellement désactivable) et j'ai commencé à compter le refactoring comme un travail de développement faisant partie de l'estimation.

Au lieu de " 2 jours de développement, 1 jour de révision / refactorisation ", ce qui susciterait toujours la même réaction de la part de la direction (" j'ai besoin que vous libériez après 2 jours, nous n'avons pas le temps de refactoriser "), j'ai plutôt dit" 3 jours de développement " et ne l'a pas décomposé davantage. La direction a perdu la capacité de discuter des parties de mon travail que je pouvais ignorer simplement parce qu'elle ne s'en soucie pas personnellement.

La refactorisation et la révision du code, du point de vue de la gestion à court terme, est un «gaspillage» du temps qui pourrait être consacré au prochain élément facturable. Mais cela améliore considérablement la qualité de vie des développeurs, ce qui réduit l'épuisement des développeurs et les personnes qui quittent, ce qui améliore considérablement le rendement à long terme de l'équipe de développement.

Dans les entreprises où la qualité du code et les développeurs quittant dans moins d'un an est un problème constant, c'est (d'après mon expérience) presque toujours attribué à la direction qui se mêle des processus de développement dont elle n'apprécie pas ou ne comprend pas la valeur. J'ai travaillé dans plusieurs entreprises comme celles-ci.

Certains gestionnaires comprennent l'importance de la qualité de vie de leurs employés, et certains ne s'en soucient pas ou s'en moquent - de toute façon, le résultat est le même. Lorsque je traite avec des gestionnaires qui appartiennent à cette dernière catégorie, je suis toujours économe avec les détails afin qu'ils ne se mêlent pas là où ils ne devraient pas se mêler.

Cette bataille ne doit être livrée qu'une seule fois si vous convaincez votre patron et suffisamment de vos collègues de mettre en place un système d'autorisations qui ne le permet tout simplement pas.

Nous utilisons GitHub, mais d'autres services ont des options similaires pour autoriser la fusion à la branche principale uniquement après que le code a été approuvé par un propriétaire de code. Naturellement, seuls ceux qui prennent le processus au sérieux devraient être propriétaires de code.

Une fois établi, cela deviendra une nouvelle norme. Il est préférable de ne pas laisser certains processus au hasard.

Les principaux arguments que je ferais à un gestionnaire pour expliquer pourquoi les révisions de code devraient être appliquées:

• la révision de code est parmi les plus des mesures efficaces pour éviter les bugs. Personnellement, je les trouve plus efficaces que les tests (même si on devrait avoir les deux!). Un bon développeur peut empêcher le pire de la part d'un certain nombre de développeurs moins expérimentés ou motivés.
• il suffit d'un seul bogue sérieux pour provoquer une perte potentiellement grave de fonctionnalités et / ou de données. Pire encore, d'une certaine manière, est la corruption des données, qui peut ne pas être détectée pendant un certain temps et rendre les procédures de récupération comme les sauvegardes pratiquement inutiles. Cela dépend bien sûr de votre produit.
• les bogues vont probablement entraîner un coût direct pour l'entreprise en termes de perte de revenus et / ou de clients (encore une fois, cela dépend du produit, mais peu de gens peuvent "se permettre" de être criblé de bugs)
• en prime, les avis sont un excellent outil de formation

Les utilisateurs finaux (ventes, support client, clients / clients / partenaires, etc.) ne doivent pas avoir un accès direct à l'équipe de développement en général. (Si le secrétaire, les vendeurs ou le service client de triage appelle / envoie un e-mail directement aux développeurs, cela doit être résolu et ils doivent contacter l'interface côté métier de l'équipe ... c'est-à-dire le gardien.)

L'équipe de développement doit adresser toute demande concernant l'état d'un correctif / changement / fonctionnalité au gardien de l'équipe (responsable technique / d'équipe, BA, PM, PO, peu importe).

Comme c'est impossible pour isoler complètement une équipe de développement du reste de l'organisation, il est important que le gardien ne soit pas un "oui", soit fier de son travail et comprenne le concept de "la hâte fait du gaspillage".

Si vous faites une approche agile du développement avec des sprints / rétrospectives, en tant que membre de l'équipe de développement, vous pouvez en parler dans la rétrospective. "Nous avons eu beaucoup de relations publiques sans test ni vérification suffisantes, nous devons travailler là-dessus." C'est précisément la raison pour laquelle les rétrospectives sont une chose - "Qu'est-ce qui a bien fonctionné, qu'est-ce qui a mal tourné, que pouvons-nous faire pour réparer les problèmes?"

Si l'un de ces RP provoque le signalement d'un vous voyez que le bogue a été signalé, si vous pouvez le lier au ticket d'origine, faites-le. Assurez-vous également qu'il est attribué à la personne qui l'a introduit (uniquement parce qu'il a l'expérience la plus récente dans ce domaine du code et sera le plus susceptible de résoudre le problème rapidement, bien sûr, pas parce que "vous l'avez cassé, vous corrigez-le ").

Il existe de nombreuses façons de résoudre ce problème - certaines auront plus de succès que d'autres, et cela dépend en grande partie des processus de votre organisation, ainsi que de la personnalité de votre équipe ( y compris votre superviseur).

Les processus doivent être conçus pour que le travail soit effectué avec précision et rapidité. Si les gens contournent régulièrement le système et que le système est bien conçu, vous devriez être en mesure de citer un certain nombre de problèmes qui ont été générés par le contournement. Vous et / ou votre patron (peut-être votre patron armé de vos données) devez dresser une liste précise de ces problèmes - cela a beaucoup plus de poids que de se plaindre simplement du contournement. Si le contournement est aussi courant que vous le dites et que vous ne pouvez pas faire une telle liste, les processus sont erronés. Ils empêchent en fait de faire du bon travail. Il est temps de revoir attentivement le processus. Les étapes de révision éludées ne créent pas de problèmes, alors débarrassez-vous-en. Voir quels problèmes auraient été détectés par quelles critiques. L'organisation doit ensuite définir quels examens sont obligatoires, appliquer ces normes et faire des examens une priorité afin qu'ils aient lieu en temps opportun afin qu'ils ne ralentissent pas trop le travail.

Votre entrée est inutile si elle n'est pas écrite. Par conséquent, je propose de mettre en place un système de journalisation, qui enregistre toutes les actions, effectuées sur une certaine tâche:

Une fois que quelqu'un a implémenté quelque chose, le hachage de validation est ajouté au rapport de bogue, et chaque tâche supplémentaire (revue de code, tests unitaires, ...) est également ajouté au rapport de bogue, de telle manière que vous pouvez facilement trouver les questions suivantes:

• Quel pourcentage des rapports de bogue réellement a réussi la révision du code?
• Quel pourcentage des rapports de bogue ont effectivement passé toute la chaîne de développement?
• ...

possible de consigner pourquoi quelque chose n'est pas fait:

• examen du code non réussi en raison de la priorisation de l'entreprise.
• Tests unitaires incomplets (seulement 20% des tests sont effectués)
• ...

Sans une telle journalisation, vous criez simplement dans le noir.

Vous avez raison. Tout le monde dans cette situation a tort.

Il semble que vous deviez continuer à être "ce type" qui agace tout le monde en insistant sur le processus . Votre patron ne prend pas le leadership à ce sujet, vous devez donc le faire à la place. En poussant directement vers Master, cela signifie que ce n'est qu'une question de temps avant que votre produit n'aura une échappatoire de qualité qui aura un impact sur vos clients et sur votre équipe.

Vous voulez être la personne qui dit "Je vous l'ai dit" dans ce cas et qui a la communication (e-mails, etc.) pour le sauvegarder. Cela devrait vous mettre dans une meilleure position - vous pourriez même vous retrouver avec le travail de votre patron.

Une autre chose à considérer est de demander de meilleurs outils qui permettent aux gens de suivre le processus et plus difficile à forcer à maîtriser. GitHub et GitLab ont une fonctionnalité de branche protégée qui permet uniquement aux propriétaires de projet de pousser vers master. Vous pouvez même verrouiller votre référentiel afin que les demandes de fusion doivent être approuvées par un autre développeur et une personne chargée du contrôle qualité avant qu’elles ne soient fusionnées. Vous pouvez également obtenir un serveur de génération qui exécute automatiquement des tests unitaires sur une demande de fusion / extraction. Il semble que votre patron soit d'accord avec cela même si, il ne devrait donc pas être trop difficile de le convaincre de commencer à utiliser de meilleurs outils.

N'attendez pas seulement que les choses changent après que quelqu'un a remarqué une grosse erreur. Vous n'avez aucun contrôle sur ce qui se passe si la direction remarque que l'équipe de développement fait de grosses erreurs. Appelez les problèmes tôt et souvent pour vous-même autant que pour le reste de l'équipe.

Bien sûr, si vous êtes fatigué de vous battre, vous avez toujours la possibilité de partir, mais cela pourrait être une opportunité d'avancement de carrière pour vous si vous choisissez de rester.

J'ai eu le plaisir d'assister à un cours Agile donné par Bob Martin ("Oncle Bob"). Si vous ne le connaissez pas, il est l'un des fondateurs de ce que nous appelons Agile.

Le but d'Agile est d'obtenir «cette fonctionnalité que le client veut voir le 1er octobre» devant le client le 1er octobre OU, indiquez très clairement à votre direction le 1er juillet que vous n'allez jamais terminer cette fonctionnalité avant le 1er octobre. À son tour, votre direction indique clairement à votre client le 2 juillet qu'il ne verra pas cette fonctionnalité le 1er octobre. À moins que certains types de changements / compromis ne soient convenus. C'est ce que la direction est censée faire.

Donc, malgré tous les pièges techniques d'Agile en place, il est clair pour moi que votre entreprise ne fait pas vraiment la partie importante. La direction doit savoir ce que veut le client et quand il le veut. Ils ont besoin de visibilité (une métrique quantitative fiable) sur où se trouvent les développeurs. Ces informations doivent être continuellement discutées et ajustées avec le client au fil du temps. C'est Agile.

Les révisions de code, le TDD, la programmation par paires et la refactorisation sont des tâches techniques qui permettent une bonne qualité logicielle et une bonne exécution. Cependant, ces éléments à eux seuls ne signifient pas que l'entreprise utilise un processus Agile. Les responsables doivent gérer à l'aide de données obtenues à partir de ces processus intégrer les commentaires des clients pour ajuster les délais selon les besoins. C'est aussi simple que cela.

La situation dans laquelle vous vous trouvez est que les développeurs essaient d'utiliser de bonnes techniques de fabrication de logiciels dans une entreprise qui n'utilise pas de processus de gestion Agile. Cela ressemble au chaos, où diverses personnes font diverses promesses de manière non coordonnée. En tant que développeur, vous ne pouvez rien y faire.

Le point de vue des autres développeurs sur la situation est qu'ils seront probablement ici pour une autre année au plus, donc laisser le code pourrir coûte moins cher que des disputes quotidiennes sur le processus avec diverses personnes qui n'apprécient pas une ingénierie minutieuse.

Je pense que c'est le problème principal. Si les développeurs ont l'impression de ne rester dans l'entreprise que pendant une courte période, sauter les meilleures pratiques pour faire les choses ne semble pas être un gros problème.

Pourquoi les développeurs ont-ils l'impression de l'être ne restera-t-il dans l'entreprise qu'une «année au plus»? Cela semble être une période assez courte pour quiconque envisage de travailler pour une entreprise.

Il existe plusieurs façons de faire le développement organisé, selon l'équipe et le produit. Le flux qui est maintenant généralement poussé suppose que tout le monde travaille sur tout et apporte des changements fréquents mais mineurs à la même branche principale, mais via la révision du code et les demandes d'extraction.

Ce n'est pas la seule façon de faire le développement. Si "les processus ne sont pas suivis" encore que le développement se déroule bien, peut-être que d'autres règles et processus sont effectivement suivis: programmation par paires, propriété du code, branches de publication, branches de fonctionnalités, branche de développement, développement piloté par les tests ou quelque chose du genre.

Si tel est le cas, il peut être préférable de découvrir et de capturer les processus réels plutôt que d'essayer de corriger ce qui n'est probablement pas interrompu.

Que puis-je faire à ce sujet?

Votre patron vous a dit que vous pouvez repousser afin que j'évite de me sentir sous pression en ignorant la communication qui est conçu pour vous faire pression pendant que vous travaillez déjà sur un élément. Cela entraînera les autres à cesser d'essayer de vous faire pression.

Après avoir lu quelques autres commentaires sur la culture d'entreprise: vous ne pouvez améliorer la culture d'entreprise que si vous êtes dans un poste de gardien (pas nécessairement de gestion) où vous pouvez bloquer quelque chose de se déployer et votre patron vous soutiendra. Cela implique que le grand-père soutiendra votre patron ... que le patron du grand-père le soutiendra et ainsi de suite.

Je salue le commentaire de Gregory Currie: "Il y a une différence raisonnablement grande entre dire quelqu'un quelque chose, et convaincre quelqu'un. Dire à quelqu'un dépend de l'autorité, convaincre peut être fait de plusieurs façons "

J'ai travaillé dans des endroits où la valeur de faire les choses de la bonne façon ne pouvait pas être montré parce que la direction a continué à autoriser des horaires irréalistes. Je ne l'ai pas vu fonctionner là où les gens sont convaincus sans une autorité soutenant de bons processus.

Habituellement, si les choses vont d'une certaine manière, c'est parce que c'est exactement ce que la direction veut, peu importe ce qu'elle dit tu. Ce type avec qui vous travaillez et qui n'a aucun souci de la qualité a été embauché par quelqu'un qui savait qu'il était comme ça ou qui s'en fichait. Si vous avez un délai déraisonnable, c'est parce que plusieurs personnes au-dessus de vous en êtes d'accord. Si vous ne pouvez pas imaginer pourquoi du code de mauvaise qualité est publié, votre patron peut imaginer pourquoi et comprend pourquoi.

En fin de compte, tout ce que nous faisons en tant que développeurs (dans une entreprise) est motivé par les besoins de l'entreprise. Le côté commercial peut avoir une raison légitime de vous forcer à précipiter le code comme s'ils savaient que l'entreprise échouera dans un court laps de temps si les clients ne peuvent pas voir de nouvelles fonctionnalités et attendre que les fonctionnalités soient de meilleure qualité prendrait aussi. longtemps.

J'ai vu des entreprises où elles ont eu la difficulté que vous décrivez. Et puis dans les 1-2 ans, tout le monde est licencié. La direction savait que cela arriverait bien avant les développeurs.

Parlez à nouveau à votre patron. Votre patron doit déclarer que c'est désormais la loi . S'il ne veut pas de combats constants, inventez des règles suffisamment strictes pour les exceptions afin que les gens ne les prennent pas à la légère.

Si cela dure trop longtemps, les gens s'y habitueront et il sera de plus en plus difficile de changer. Peut-être que le patron doit impliquer son patron.

Vous seul ne pouvez pas faire grand-chose sans votre soutien. Vous pouvez essayer de persuader vos collègues que suivre le processus est bon pour leur CV, et la capacité de dire poliment non fera avancer leur carrière n'importe où. C'est vrai, et aussi difficile à vendre.

Je suis d'accord avec les autres réponses selon lesquelles le processus doit être en place pour une raison et suivi.

Je suis également d'accord pour dire que c'est le travail de votre patron de lutter contre ce combat avec les parties prenantes de l'entreprise et cela devrait être à eux d'expliquer que la sortie à la vitesse du cou augmente considérablement le risque de problèmes d'arrêt de la série (fin de l'activité?).

Cela dit, une façon de mettre fin à ce saut de processus consiste à mettre en œuvre un correctif technique. Vous pouvez `` protéger '' la branche principale et désactiver la possibilité pour les gens d'y pousser sans processus d'examen approprié:

https://docs.github.com/en/github/administering- a-repository / definition-the-mergeability-of-pull-requests

Cela peut également être fait dans d'autres solutions de gestion de référentiel telles que TFS.

Si vous priver les développeurs de la possibilité de précipiter le code vers la production, alors la pression sur eux pour le faire est également supprimée. Cela fait monter la pression vers votre patron (là où elle devrait être) et c'est alors à eux d'avoir ces arguments.

Pour commencer - ce n'est pas de votre responsabilité de résoudre ce problème, mais c'est néanmoins une bonne chose d'être orienté processus.

Vous pouvez suggérer d'utiliser un système CI / CD qui ne permettra le déploiement que lorsque tous les critères (tests, ...) sont remplis. Sinon, le pipeline échoue et la modification est rejetée.

Si vous avez un contrôle suffisamment serré du tuyau, alors ces raccourcis échoueront. Je documenterais également clairement le processus d'exception afin qu'il y ait quelque chose à signaler lorsque le vendeur ou quiconque en a besoin d'urgence.

• Vos collègues ne voient pas de perspectives à long terme au sein de l'entreprise et n'ont donc aucun intérêt à suivre le processus.
• Votre patron se contente de faire des déclarations du bout des lèvres sur le processus et n'a aucun intérêt à faire appliquer
• Les services dépendant des logiciels ne se soucient pas des défauts, juste des choses qu'ils peuvent montrer aux clients hier, donc ils ne se soucient pas non plus du processus.

Il s'agit d'un scénario extrêmement courant dans les entreprises qui ne comprennent pas que leur produit le plus important n'est pas la marchandise ou le produit qu'elles vendent, mais le logiciel qui le sous-tend. Ces entreprises ne donneront jamais la priorité à faire des logiciels «correctement» parce qu'elles n'y voient aucune valeur.

À moins que vous ne soyez en position de pouvoir dans une telle entreprise, vous ne pouvez rien faire pour corriger cela la perception. En tant que tel, votre seule option - si vous souhaitez conserver votre santé mentale - est de trouver un emploi ailleurs, avec une entreprise qui comprend que des logiciels de qualité sont la base de leur succès, et même de leur existence, à l'avenir.

Une chose minable à considérer, en réponse à cette citation de la question.

Mon équipe a une variété de processus de développement que le code est techniquement censé passer pour accéder à la branche master. Des tests unitaires et une révision de code.

Non, vous ne le faites pas. Le processus qui se produit est le processus que vous avez et le processus que l’équipe, l’ensemble de l’équipe (à partir des responsables), apprécie réellement.

S'il y a un document quelque part ou un ensemble nébuleux d'idéaux dans la tête de quelques développeurs, c'est bien, mais ce n'est pas votre processus. Une chose que vous pouvez faire est de vous familiariser avec votre processus réel, de vous rendre compte qu'il n'est pas idéal et de vivre avec (et de communiquer les conséquences) ou de convaincre l'équipe de développement de mettre en œuvre des changements structurels qui appliquent de manière plus tangible les processus que vous souhaitez, tels que comme: la fusion ne peut pas se produire physiquement en dehors d'une demande de tirage approuvée, des pipelines de construction automatisés, etc.

Bonne chance - c'est une situation de merde en tant que développeur

Je ne suis pas un expert en la matière, mais mes 2 ¢ seraient ceci:

Chaque fois que des tests / processus sont repoussés, faites une estimation du nombre de bogues que cela équivaut, plus , les dommages que cela représente en termes de perte d'argent pour l'entreprise, plus les heures de travail qui seront nécessaires si cela devient un correctif hérité (qui est généralement beaucoup plus long que le temps nécessaire pour suivre le développement piloté par les tests dans la première place). Malheureusement, cela nécessite évidemment un peu de travail de votre part, ce qui va probablement au-delà de votre description de poste, mais en même temps, des calculs approximatifs sont bons, et vous pouvez probablement avoir une idée pour cela des rapports de bogues précédents liés à des tests manqués, etc.

Assurez-vous de vous en tenir à ces chiffres et mettez-les à jour chaque fois que les tests sont ignorés. Puis, à la fin de chaque réunion, dans un ton business-as-usual (mais pas passif-agressif), notez occasionnellement "la dette technique accumulée jusqu'à présent", selon ces chiffres. Les gens vont rire au début, puis peut-être en avoir assez de l'entendre, mais une fois que ce nombre commencera à grimper, cela pourrait amener les gens à s'en apercevoir. À un moment donné, j'espère que cela atteindra un point de basculement, et la discussion pourrait se dérouler comme suit:

Patron: Informez-moi de la mise en production d'hier.

Vous: Certainement. Hier, nous avons poussé 5000 lignes de code vers git. En raison de l'urgence, nous avons sauté les tests selon la demande, estimée à environ 30 tests unitaires pour ce commit. D'après l'expérience précédente, nous avons constaté que 1 test unitaire ignoré sur 3 se manifeste par un rapport de bogue utilisateur 2-3 mois plus tard, avec un coût estimé à environ 10000 $ en ventes et 40 heures-personnes de correctifs hérités par bogue. , donc l'engagement d'hier coûte environ 100 000 $ de pertes et 400 PH de dette technique. Compte tenu de notre précédente estimation de la dette technique de 470 bogues, moins 30 bogues spécifiquement liés aux tests manquants que nous avons corrigés au cours du dernier mois (nous avons passé environ 1200PH à le faire), plus la dette technique estimée de 10 bogues aujourd'hui, cela apporte notre endettement aujourd'hui jusqu'à environ 450 bogues, ce qui, pour une estimation de 10 000 $ / 40 PH par bogue, cela entraîne une perte estimée à 4 500 000 $ pour l'entreprise plus 18 000 PH de dette technique jusqu'à présent .

Patron: ... Wtf. Ok, bien, réfléchissons à ça. Pousser tôt sans tests a généré pour nous X $ de plus que si nous avions poussé tard ... mais si ce que vous dites sur les tests est vrai, cela nous a également coûté Y $. Peut-être devrions-nous réfléchir à la question de savoir si le coût de la dette technique $ Y compense réellement le bénéfice d'expédition anticipée de X $ dans ce cas ... de combien de temps supplémentaire avez-vous de toute façon besoin pour appliquer ces tests?