🍓 👩🏻 👵🏼 Pourquoi les développeurs sont si lents: problèmes courants et leurs solutions 🛬 🙇🏿 ⏰

Bonjour, Habr! Je vous présente la traduction de l'article Pourquoi les équipes de développement sont lentes: bourrages logiciels courants et solutions par Eric Elliot.

Si vous aimez écouter plus que lire, alors au format audio, la traduction est disponible sur Yandex.Music et Apple Podcasts.

Voyons ce qui cause des perturbations dans le processus de développement logiciel, et ce que vous pouvez faire en tant que manager. Il peut y avoir de nombreuses raisons, donc notre liste, bien sûr, sera loin d'être exhaustive. Au lieu de cela, nous nous concentrerons sur quelques-uns des problèmes les plus courants :

Attentes irréalistes
Trop de tickets ouverts
Portée incontrôlée des tâches
Examen du code d'accumulation
Mauvaise préparation
Développeurs Burnout
Bugs
Roulement de personnel

Un développement lent n'est pas à l'origine du problème. Il s'agit d'un symptôme des autres problèmes répertoriés. Dans 100% des cas, si l'équipe de développement travaille trop lentement, c'est la faute du leader. Mais la bonne nouvelle est que vous pouvez y remédier. Examinons chacun des éléments plus en détail pour comprendre ce que nous pouvons faire avec chacun d'eux.

Attentes irréalistes

La plupart des problèmes de productivité des développeurs n'affectent généralement pas le développement lui-même. C'est plutôt un problème de notre perception du processus de développement en tant que gestionnaires et parties prenantes.

La partie la plus difficile du travail d'un gestionnaire est de comprendre que l'écriture de code prend autant de temps que cela et essayer d'accélérer ce processus ne fera que le ralentir et augmenter le nombre de bogues. La patience est notre tout.

Le plus souvent, le problème de la vitesse de travail n'est pas que l'équipe n'est pas suffisamment productive, mais qu'elle fait face à des attentes élevées. Et ceci est entièrement de votre responsabilité. Si la pression vient d'un leadership supérieur, alors vous n'avez pas formé leur vision correcte de la situation. Si la pression vient de vous, lisez la suite.

Nous oublions souvent que le logiciel que nous créons est quelque chose de fondamentalement nouveau. Si vous avez déjà un logiciel qui fait de même, achetez-le, utilisez-le, importez le module, etc. Pas besoin de le réécrire à partir de zéro. Le nouveau logiciel est unique. Il fait quelque chose de nouveau ou fait quelque chose de différent. C'est alors que nous le créons. Et puisque nous ne l'avons pas encore fait, comment savons-nous combien de temps cela prendra?

Les constructeurs construisent des murs préfabriqués au même rythme et peuvent donc donner des estimations plus ou moins précises en fonction des observations. Les développeurs de logiciels ne disposent pas de données fiables. Ce problème est exacerbé par les différentes vitesses des différents développeurs, et il peut varier d'un ordre de grandeur.

Comme l'écrit Steve McConnell, auteur de The Perfect Code: «La conclusion selon laquelle il existe une différence significative entre la productivité des différents programmeurs a été confirmée par de nombreuses études de développeurs professionnels (Curtis 1981, Mills 1983, DeMarco et Lister 1985, Curtis et al. 1986, Card 1987 , Boehm et Papaccio 1988, Valett et McGarry 1989, Boehm et al.2000). Nous ne disposons pas de suffisamment de données pour prédire combien de temps il faudra pour terminer notre projet. Nous découvrirons ce que l'échelle et la complexité commencent déjà à faire et ce processus est souvent plein de surprises. «Le développement n'est pas seulement de la planification, mais aussi de la recherche, même si nous avons soigneusement essayé de tout prévoir.»

« 90 10 , . 10 90 »
— , Bell Labs

Il y a plusieurs raisons à des attentes élevées qu'un gestionnaire peut contrôler. L'une des raisons fondamentales est de mesurer les mauvaises choses.
Vous connaissez peut-être le célèbre dicton de Peter Drucker: «Ce qui est mesuré est contrôlé.»

Et bien sûr, c'est un excellent conseil. Bien sûr, nous devons mesurer! Mais nous manquons l'essence de cette citation, d'ailleurs, nous renversons son sens.

L'idée est: «Ce qui est mesuré est contrôlé, même s'il est mesuré et essayer de contrôler est complètement inutile, même s'il nuit aux objectifs de l'organisation.»

Deux exemples de choses qui ne valent pas la peine d'être mesurées:

Graphiques prédictifs de burndown montrant un graphique du nombre de tickets ouverts prédisant la date de fin d'un projet basé sur des mesures récentes de la vitesse de travail;
Nombre de tickets fermés par le développeur, indiquant le nombre de tâches effectuées par un développeur individuel.

La mesure de ces deux choses a coûté à d'innombrables entreprises d'énormes pertes en raison de la perte de productivité, des employés et d'autres coûts.

Diagrammes de progression des tâches

De nombreux outils logiciels tentent de prédire la date d'achèvement du projet, en fonction de l'échelle actuelle des tâches et de la vitesse de travail. Le problème est qu’aucun d’entre eux ne prend en compte le volume inexploré de tâches. De plus, cela est impossible, car le temps nécessaire à la fermeture d'une tâche peut varier d'un ordre de grandeur pour différentes tâches, ce qui peut fausser considérablement les valeurs moyennes qui ont été calculées pour les tickets déjà fermés.

Si vous définissez un délai basé sur la date du graphique, considérez que vous n'avez pas respecté les délais. La seule chose qui peut vous sauver est de jeter autant de tâches hors de portée que possible à l'avenir.

Lorsque vous basez vos notes sur des informations incomplètes, vous et votre équipe les paierez certainement. Des estimations irréalistes créent des attentes irréalistes. Cela peut être un vrai désastre si vous partagez également ces évaluations avec l'équipe marketing, les clients et la presse.

Tous les graphiques ne sont pas mauvais. Ceux qui n'essaient pas de prédire l'avenir peuvent être utiles. Ils peuvent nous avertir de la propagation du projet et des explosions combinatoires lorsque vous voyez que le nombre de tickets augmente au lieu de diminuer ou de monter et descendre. Les diagrammes de tâches utiles montrent des tâches déjà clôturées de manière réaliste, plutôt que d'essayer de prédire l'avenir.

Un bon indicateur est une courbe qui a des hauts et des bas, mais dans l'ensemble, elle descend, ce qui montre une diminution du nombre de tâches ouvertes à la fin du projet.

Calendrier du projet où le nombre de billets est réduit

Calendrier du projet où le nombre de billets est réduit

Un projet souffrant d'un périmètre envahissant sera en revanche représenté par une courbe qui se courbe vers le haut.

Calendrier d'un projet noyé dans de nouvelles tâches

Calendrier d'un projet noyé dans de nouvelles tâches

Gardez à l'esprit que le point d'observation de cette courbe n'est pas d'essayer de la changer, mais de reconnaître et de résoudre les problèmes sous-jacents. Nous ne voulons pas que les programmeurs arrêtent simplement d'ouvrir de nouveaux tickets.

L'objectif est la transparence des processus, pas une belle courbe descendante.

Méfiez-vous du principe de Goodhart : «Si une dimension devient un objectif, alors elle cesse d'être utile.»

Aucune prévision n'est nuisible. Lorsque vous avez une échéance stricte (par exemple, vous essayez de sortir un jeu avant le Black Friday), vous pouvez contrôler systématiquement la portée en fonction de la vitesse moyenne de travail, afin que vous sachiez quand commencer à couper la portée. Si les prévisions vous indiquent que vous ne terminerez pas avant décembre, faites-lui confiance. Le moment est venu de prioriser et de réduire.

La règle d'or pour les prédictions de ce genre est:
«Si la prédiction dit que vous pouvez faire quelque chose à une date donnée, ne le croyez pas, si elle dit que vous ne pouvez pas le faire, croyez-le.

Billets fermés par un programmeur

L'idée de raconter toutes les tâches effectuées par un programmeur, puis de comparer ce chiffre avec la valeur moyenne est très tentante. Mais je vous exhorte à résister à cette tentation. Il existe des tonnes de meilleures façons de collecter les données de productivité des développeurs.

Il y a deux défauts fondamentaux dans le calcul des tâches fermées. Premièrement, les tâches ne sont pas identiques entre elles par leur complexité et leur importance, et en fait, la valeur du travail dépend de la loi de puissance. Une petite poignée de tâches représente un ordre de grandeur plus important que la «moyenne». C'est comme la différence entre la fondation d'un gratte-ciel et le dernier clou bouché. Ainsi, simplement en comptant le nombre de tickets fermés, il est impossible de connaître exactement la valeur d'un employé.

Il y a plusieurs années, j'ai travaillé sur un panier d'achat pour un leader mondial de la vente au détail. Une fois, j'ai arrêté d'écrire du code et de fermer les tickets dans Jira et j'ai ajouté un autre ticket: "Étude d'utilisabilité".

Je travaille sur une refonte du panier depuis plus d'un an et la date de sortie approche à grands pas. Jusqu'à ce moment, aucun test de convivialité du nouveau processus de commande n'était effectué par l'utilisateur, ce qui a donc pris une semaine. Nous avons donné un accès rapide aux mille partisans les plus fidèles et les avons interrogés pour recueillir leurs commentaires.

J'ai analysé les résultats et trouvé une tendance alarmante dans les sondages et les journaux: la fréquence des utilisateurs quittant le site au stade du panier était trop élevée et était exprimée en un nombre à deux chiffres. Un vrai désastre allait arriver! J'ai donc commencé à travailler et je prévoyais d'enregistrer de nouveaux tests d'utilisabilité avec une présence personnelle. J'ai assis les débutants derrière notre nouveau panier, leur ai donné quelques tâches et les ai laissés seuls avec le site. Je n'ai rien dit, je les ai juste regardés utiliser la nouvelle interface.

J'ai remarqué que lors du processus de commande, les gens ont des difficultés avec les erreurs dans les formulaires. Ayant ces données, j'ai légèrement corrigé notre projet open source sur le github (sans rien remarquer dans le Gira). Après un certain temps, nous avons effectué un autre test. Les utilisateurs sont devenus beaucoup moins susceptibles de quitter la page du panier: la différence de revenu pour l'entreprise est de 1 million de dollars par mois.

Entre-temps, mes collègues ont chacun fermé 10 à 15 billets. Vous pourriez dire que je pourrais simplement obtenir plus de tickets de test d'utilisabilité pour refléter la réalité. Mais alors je devrais faire mille billets supplémentaires, ce qui ne ferait que créer du bruit et nécessiterait beaucoup de temps.

Une autre raison pour laquelle le décompte des tickets fermés est inefficace est que les membres les plus efficaces de l'équipe sont également les personnes vers lesquelles tout le monde se tourne pour obtenir de l'aide. Ils connaissent le mieux la base de code, ou ils sont de grands développeurs, ou ils ont des compétences de communication exceptionnelles. Ils vous aident à parcourir l'arriéré des demandes de tirage, à examiner le code des autres programmeurs, à former et à encadrer vos coéquipiers. Ils sont les plus productifs de l'équipe, car ils aident le reste de l'équipe à doubler la vitesse de travail. Peut-être que les tickets qu'ils ferment sont la création de frameworks ou de bibliothèques qui augmentent la productivité de toute l'équipe. Ils font la plupart du travail tandis que les autres sont reconnus.

Si vous ne faites pas attention, puis découvrez la contribution de vos développeurs les plus productifs. La meilleure façon de savoir ce que les programmeurs font pour un projet est de leur demander. Demandez à l'équipe qui, selon eux, est son collègue le plus utile.

Habituellement, les informations reflétées dans ces commentaires sont très différentes des données qui peuvent être obtenues simplement en comptant le nombre de billets.

Collectez des données de performances, mais n'approchez pas chaque développeur avec une seule mesure. Le développement est un sport d'équipe et chaque participant au processus y joue un rôle. Il n'y a pas de méthode magique unique qui conviendrait à tout évaluer, sans exception.

Trop de tâches ouvertes

Cela semble simple - ouvrez un ticket dans le tracker et continuez. Mais chaque tâche dans le tracker nécessite un cycle de traitement complet.

Ils doivent être triés, hiérarchisés et assignés à un artiste avant que les développeurs puissent commencer à les implémenter. Ce travail est répété chaque fois que les développeurs ferment une tâche et choisissent la suivante. Si vous avez un chef de projet ou un maître de mêlée, ils font ce travail chaque fois qu'ils redéfinissent la liste des tâches (ce qui se produit généralement au début du sprint ou juste une fois toutes les deux semaines).

Ensuite, le développeur doit se plonger dans le contexte de la tâche, comprendre l'essence du problème, décomposer les tâches complexes en sous-tâches, et seulement alors vous pouvez enfin commencer à exécuter.

Créer et lire des billets représente beaucoup de travail, mais c'est comme un faux travail. Il s'agit d'une méta-tâche. Elle est nécessaire pour commencer de vraies tâches. A eux seuls, ils ont une valeur nulle. Et cela prend du temps chaque fois que les programmeurs choisissent la tâche suivante. Moins il y a de tickets à la fois dans le tracker, mieux c'est. Moins les tâches à faible priorité sont suspendues dans le backlog, plus les chances sont grandes que le développeur choisisse une tâche à haute priorité.

S'il y a un bug dont un seul utilisateur a parlé, quelle est son importance pour nous? Il a touché une personne, mais avons-nous des bugs que plus de gens ont remarqués? Existe-t-il de nouvelles fonctionnalités qui seront plus utiles que la correction de ce bogue?
Probablement oui.

Supprimez le bruit de l'arriéré. Supprimez ce que vous ne prévoyez pas de faire dans un avenir proche.
Si cela est vraiment important, ajoutez-le plus tard lorsque cela sera possible.

Taille de la tâche non contrôlée

J'aime demander aux développeurs de mon équipe de diviser le travail en tâches qu'ils peuvent accomplir en une journée. C'est plus compliqué qu'il n'y paraît, car cela nécessite la possibilité de diviser des tâches complexes en petites, qui peuvent également être testées séparément du reste de l'application.

Exemple: vous effectuez un nouveau processus de paiement sur un site. Vous n'avez pas besoin de mélanger les composants de l'interface utilisateur, la gestion des états et la communication avec le serveur en un seul commit géant impliquant 13 fichiers, tous profondément liés à la base de code actuelle, car le résultat sera une énorme demande de tirage difficile à examiner et à fusionner.

Au lieu de cela, commencez par un module d'état de panier côté client testé indépendamment et effectuez une demande d'extraction pour cela. Ensuite, créez l'API du serveur et faites-lui un PR distinct. Ensuite, écrivez un composant d'interface utilisateur qui importerait l'état à partir du module et communiquerait avec l'API du serveur. Chacune de ces tâches peut être divisée en tâches distinctes, bien que tout cela soit essentiellement une grande caractéristique. En prime, les tâches peuvent être réparties entre plusieurs programmeurs et accélérer le développement, en profitant de la taille de l'équipe.

Le sélecteur de fonctionnalités rendra ce processus plus facile et plus sûr, vous permettant de désactiver les fonctionnalités développées jusqu'à ce qu'elles soient prêtes à être incluses en production.

Remarque:N'essayez pas de le faire sans une bonne couverture des tests de fumée. Vous devriez pouvoir vous assurer que vous n'avez rien cassé en déployant des fonctionnalités semi-finies. Assurez-vous de vérifier comment cela fonctionne à la fois sur et hors tension.

Accumulation de tâches par révision de code

Lorsque les développeurs piquent plus qu'ils ne peuvent avaler, le résultat est une énorme demande de traction en attente d'examen et de vérification.

Il s'agit de la phase d'intégration en «intégration continue» (CI). Le problème est que plus le RP reste ouvert longtemps, plus il y passe de temps. Les développeurs l'ouvriront pour voir s'ils peuvent aider à la limiter. Ils laisseront des commentaires, demanderont des modifications et la demande sera retournée à l'auteur pour apporter des modifications et approuver ces modifications. En attendant, toutes ces demandes de tirage en cours s'éloigneront davantage du maître.
Lorsque plusieurs développeurs ont l'habitude de faire des commits très importants, le nombre de demandes de pull commence à augmenter comme une boule de neige et l'intégration devient de plus en plus compliquée.

Exemple: Bob modifie un fichier que Jane gouverne également, mais n'a pas encore hypothéqué. La demande de tir de Bob est maintenue en premier et PR Jane devient un commit plus loin du maître. Désormais, elle ne peut pas conserver sa branche tant qu'elle n'a pas résolu tous les conflits avec le code de Bob. Multipliez cette situation par le nombre de programmeurs qui travaillent avec le même code dans votre projet. Ces «embouteillages» donnent lieu à un excès d'actions.

Nous calculons le nombre de ces actions dans le scénario standard:

Bob et Jane commencent à travailler dans la même branche (0 actions)
Bob apporte des modifications et s'engage dans sa branche. Jane fait de même (2 actions)
Le code de Bob va au maître. Jane télécharge les modifications de Bob et découvre un conflit. Elle le corrige et valide le résultat dans son fil. (3 actions)
Jane ouvre une demande d'extraction. Bob note que ses changements dans son code vont casser quelque chose qu'elle n'a pas pris en compte. Jane apporte des modifications en fonction des commentaires de Bob et valide à nouveau le code (4 actions)
PR Jane fusionne enfin. Seulement 4 actions.

Considérons maintenant une situation dans laquelle les validations seraient moindres et les demandes de tirage scintilleraient plus rapidement:

Bob fait un petit changement et son code tombe dans le maître (1 action)
Jane télécharge la nouvelle version de l'assistant et écrit son code en tenant compte des changements de Bob. (2 actions)
Puisque commettre Jane est également petite, il est rapidement détenu par le maître. Total de deux actions seulement.

Lorsque nous créons de petits PR, nous réduisons considérablement la nécessité de refaire le code, ce qui est dû aux conflits et à la complexité du code.

Mauvaise préparation

L'industrie informatique est terrible en termes de formation et de support. Les universités enseignent en profondeur des algorithmes qui sont déjà intégrés dans des bibliothèques standard et seuls quelques programmeurs les écrivent à partir de zéro.

Alors que les bases du développement telles que les principes d'abstraction, de connectivité et d'engagement, la modularité par rapport à la conception monolithique, le travail avec les modules, la composition des fonctions, la composition des objets, la conception des cadres et l'architecture des applications sont négligés. En raison de la croissance explosive de l'industrie, environ la moitié des développeurs ont moins de cinq ans d'expérience et 88% des spécialistes pensent que la formation ne leur ferait pas de mal.

Les équipes travaillent lentement parce qu'elles ont une mauvaise compréhension de ce qu'elles font et que personne ne veut leur enseigner.

Notre tâche en tant que managers est d'embaucher des spécialistes expérimentés qui pourraient guider nos équipes et leur consacrer du temps.

Ce qui peut être fait:

Revue de code: les développeurs apprennent beaucoup en apprenant le code des autres
Création de paires d'ingénieurs seniors et juniors: il n'est pas nécessaire de créer des paires permanentes, une union unique pour résoudre un problème spécifique fonctionne très bien.
Temps spécial consacré au mentorat: embauchez des professionnels expérimentés qui aiment bien apprendre et bien communiquer et leur donner le temps de partager leur expérience avec les développeurs juniors, cela aidera ces derniers à comprendre comment ils développent leurs compétences.

Burnout

Faire griller votre équipe est un grand revers pour le leader que de ne pas respecter les délais.

L'épuisement professionnel est un problème grave qui peut entraîner la perte de développeurs, le roulement du personnel, des coûts énormes, une augmentation du facteur de graves ( facteur Bus - une mesure de la concentration des informations parmi les membres individuels du projet; le facteur signifie le nombre de participants au projet, après la perte duquel le projet ne peut pas être achevé par les autres participants) .

Mais, plus important encore, l'épuisement professionnel entraîne des problèmes de santé. Les conséquences de l'épuisement professionnel peuvent entraîner une déstabilisation du corps et même la mort d'une crise cardiaque ou d'un accident vasculaire cérébral. Au Japon, ce phénomène est tellement répandu qu'ils ont même un mot spécial: «karoshi».

Le leader peut épuiser toute l'équipe, annulant complètement sa productivité. Le problème de l'épuisement d'équipes entières est particulièrement fréquent dans l'industrie du développement de jeux informatiques, où le Black Friday est presque toujours une échéance difficile.

Malheureusement, «mourir, mais le faire» est un principe courant d'organisation du travail de ces équipes, bien que les managers se rendent rarement compte des dangers d'une telle approche.

Au lieu de forcer les développeurs à travailler davantage, les gestionnaires devraient reconnaître que la responsabilité de respecter les délais incombe à 100% à la direction et non aux développeurs.

La date limite est plus facile si vous utilisez les techniques suivantes:

Mieux hiérarchiser les tâches et réduire les portées
Rationalisez les processus
Reconnaître et refactoriser la confusion du code

Roulement de personnel

Les données collectées par Linkedin en 2018 ont montré que le roulement du personnel informatique est supérieur à celui de toute autre entreprise. Et c'est mauvais, car cela entraîne le risque du facteur de graves, le risque de perdre des spécialistes clés de votre projet.

De nombreuses entreprises n'accordent pas d'importance au maintien en poste de spécialistes. Examinons de plus près combien coûte le roulement du personnel.

Le placement des postes vacants coûte de 15 à 30 000 dollars. Le temps d'un ingénieur coûte en moyenne 90 $ de l'heure. Multipliez cela par environ 50 entretiens et de nombreuses heures pour répondre aux questions du débutant et l'aider à s'habituer à l'équipe. Ainsi, nous avons déjà dépensé 50 mille dollars, mais ce n'est pas tout.

Cela peut prendre jusqu'à un an pour qu'un nouvel employé atteigne le niveau du développeur qu'il a remplacé, avec la première fois il fera beaucoup d'erreurs et passera beaucoup de temps à les réparer.

Ainsi, l'embauche et la formation d'un nouveau développeur, les coûts d'opportunité et la perte de productivité d'une équipe qui doit former un débutant pendant un certain temps tout en effectuant une partie de son travail représentent près de 90% du salaire d'un développeur décédé. Trouver un remplaçant peut prendre plusieurs mois, puis il faudra plus de temps au débutant pour atteindre sa pleine efficacité.

Tout cela prend beaucoup de temps et les grandes équipes souffrent constamment de travaux en cours, car selon une enquête 2019 de Stack Overflow, 60% des développeurs ont changé d'emploi au cours des deux dernières années.

Au moment où le développeur commencera enfin à travailler avec une efficacité maximale, vous le perdrez.

Comment éviter la fluidité? Voici quelques conseils provenant de diverses sources:

Payez honnêtement
Augmentez régulièrement votre salaire
Laissez les gens partir en vacances
Offrir du travail à distance
Gardez des attentes réalistes
Fournir des tâches qui intéresseront le développeur
Ne laissez pas la pile technologique devenir trop vieille
Offrir des opportunités de formation et de carrière
Offrir des avantages pour la santé
Ne forcez pas les développeurs à travailler plus de 40 heures par semaine
Fournir aux employés un équipement moderne

Bugs

Si vous pensez que vous n'avez pas le temps de mettre en œuvre un processus de développement de haute qualité, vous ne pouvez vraiment pas vous en passer.

Selon le livre «Evaluating Software Engineering Technologies» (David N. Card, Frank E. Mc Garry, Gerald T. Page, 1978), des processus bien optimisés peuvent réduire les erreurs sans augmenter les coûts. La raison principale est que, selon un autre livre, "Software Assessments, Benchmarks, and Best Practices" (Casper Jones 2000), la détection et la correction des défauts est l'une des tâches de développement les plus longues et les plus coûteuses.

Les bogues sont connus pour causer le besoin de traitement de code, et plus vous les trouverez tard, plus il sera coûteux de les corriger. Lorsqu'un développeur est invité à corriger un bogue déjà découvert en production, cela l'arrache souvent à ce qu'il faisait. Dans le livre «A Diary Study of Task Switching and Interruptions» (Mary Czerwinski, Eric J. Horvitz, Susan Wilhite), il est dit qu'une tâche dont nous sommes distraits peut prendre deux fois plus de temps et contenir deux fois plus d'erreurs, ce qui suggère que les bogues de haute priorité sont à certains égards contagieux: en corrigeant un, nous sommes susceptibles d'en engendrer de nouveaux.

Les bogues en production nous obligent également à accorder plus d'attention au support et sont des utilisateurs très ennuyeux et fatigants, ce qui vous coûtera finalement de l'argent. Vous devrez investir dans la réparation de l'ancienne fonctionnalité au lieu d'en créer une nouvelle.

Un bug trouvé au stade du développement peut être corrigé en quelques minutes, tandis qu'un bug trouvé en production passera par de nombreuses phases supplémentaires: rapporter un bug, vérifier, prioriser, nommer un artiste et enfin développer.

Mais ce n'est pas tout. Ce bogue aura son propre commit, sa pull request, son code de révision, son intégration et peut-être même son propre déploiement. Et à tout moment, certains tests peuvent tomber et tout le cycle CI / CD devra être recommencé.

Comme déjà mentionné, un bogue en production vous coûtera beaucoup plus cher qu'un bogue trouvé pendant le développement.

Les conseils suivants vous aideront à améliorer la qualité du processus.

Ralentissez pour accélérer. Lent signifie ininterrompu, ininterrompu signifie rapide.
Effectuer une revue de conception. La combinaison de la vérification du code et des exigences vous permet d'attraper jusqu'à 70% des bogues.
Examen du code postal. Un code bien testé est 90% plus facile à maintenir. Une heure de révision vous fait gagner 33 heures de support. Les programmeurs qui effectuent des révisions de code sont 20% plus productifs.
Utilisez l'approche TDD. Il réduit le nombre de bogues de 30 à 40%.
CI/CD. , , . , . CI/CD .
Augmentez la couverture des tests . Votre processus CI / CD doit exécuter des tests et s'arrêter si au moins l'un d'entre eux se bloque. Cela vous aidera à éviter le déploiement de bogues en production et vous fera économiser beaucoup d'argent et de temps. Votre objectif est une couverture d'au moins 70%, mais essayez de rester proche de 80%. À l'approche de 100%, vous remarquerez que la couverture des processus utilisateurs importants avec des tests fonctionnels vous donnera plus qu'une augmentation supplémentaire des tests unitaires.

Conclusion

Il existe de nombreuses façons d'influencer les performances d'une équipe, notamment:

Définissez des attentes réalistes
Suivre et contrôler le nombre de tâches ouvertes
Contrôler la taille des tâches
Ne laissez pas les tâches s'accumuler par la révision du code
Former les développeurs
Assurer un bon équilibre entre travail et loisirs
Mettre en œuvre des processus de développement efficaces
Faites attention à la rétention des employés

Pourquoi les développeurs sont si lents: problèmes courants et leurs solutions