Vous voudrez peut-être prendre quelques arguments du livre The Mythical Man-Month de Frederick Brooks. Bien qu'il ait été initialement écrit en 1975 (remanié en 1995), il reste l'un des travaux les plus importants concernant la gestion des équipes de développement logiciel.

Il est surtout connu pour codifier la loi de Brooks:

l'ajout de ressources humaines à un projet logiciel tardif le rend plus tard

Les raisons sont:

• Nouveau les développeurs doivent être informés de l'architecture existante du projet avant de pouvoir faire quelque chose d'utile. Cela prend du temps à l'équipe de développement existante.
• Il y a une limite supérieure au nombre de personnes qui pourront apporter des contributions utiles à un projet de développement logiciel en même temps. Il est souvent impossible de trouver des sous-tâches raisonnables à attribuer à de nouvelles personnes.

Un bon développement logiciel nécessite une équipe centrale stable qui travaille ensemble du début à la fin.

Votre responsable n'est peut-être pas au courant de cette règle. Il essaie donc de vous aider de la seule façon à laquelle il pense: ajouter plus de personnes à votre projet.

Le problème avec les intérimaires et les sous-traitants (divulgation, j'en suis un) est qu'il n'y a souvent pas de retour si la livraison est mauvaise.

Cela peut valoir la peine d'avoir une discussion avec votre patron sur la qualité de les temps. Embaucher à bas prix signifie déplacer les coûts plus loin, mais il finira par payer pour corriger le code.

Vous pouvez également demander à être impliqué dans le processus de recrutement en fournissant un petit test de codage pour vous assurer que les intérimaires valent vraiment la peine d'être embauchés. Rien de trop dramatique, moins d'une heure de travail pour se faire une idée de ses capacités.

Ce que vous avez écrit soulève en fait un certain nombre de signaux d'alarme suggérant que la seule solution viable est de changer votre travail. Vous avez écrit que votre responsable ne tient pas compte de l'importance et de la valeur des tests unitaires, je suppose que c'est la même chose avec l'analyse et la conception, car ces idées fausses sont généralement regroupées. Vous dites également qu'il pense que l'ajout d'un développeur temporaire pendant un mois entraînera autre chose qu'un retard supplémentaire. Apparemment, votre manager n'a pas la moindre idée de la manière dont le projet de développement logiciel doit être exécuté et il y a peu ou pas de chances qu'il change d'avis

Pourtant, vous pouvez essayer.

Pendant un 9 femmes à accoucher en un mois est un moyen populaire de «prouver» que l'ajout de personnes n'accélère pas nécessairement le travail, cela ne fonctionne généralement pas pour quelqu'un qui ne comprend pas vraiment le problème mais qui connaît mieux le problème. Plutôt que cela, utilisez l'exemple de creuser un puits.

Disons que vous devez creuser un puits de 1 m de diamètre et 15 m de profondeur. Un homme a besoin de 15 heures pour le creuser. Combien d'hommes faudra-t-il pour accomplir la tâche en 1h?

La réponse que la plupart des managers (et la plupart des gens en général) vous donneront sera que ce sera 15 hommes mais ce n'est pas vrai et c'est simple à montrer à quiconque n'a aucune idée du codage qui creuse du tout. Tout comme dans le codage, vous pouvez remplacer une personne en train de creuser par une autre. Vous pouvez (à un certain niveau) partager votre travail. Mais un seul homme rentre dans un trou de 1 m de large pour travailler. Si vous ajoutez une deuxième personne à l'intérieur, la première sera gênée par elle et ne pourra pas faire son travail.

Vous pouvez accélérer un peu le travail en échangeant une personne épuisée par une nouvelle pour qu'une deuxième personne vous aide un peu. Ce ne sera pas la moitié du temps, une sauvegarde ne dépassera probablement pas 1/3. Mais ajouter un troisième homme n'aidera probablement pas du tout. Les deux échangeront toutes les heures environ, ayant le temps de retrouver leur endurance. Donc, si vous insistez pour utiliser le troisième ouvrier à l'intérieur du trou, le seul effet sera que vous perdrez plus de temps lorsqu'ils échangent ou simplement plus d'hommes attendent leur tour, étant payés mais n'apportant aucune valeur supplémentaire. Pas de gain au mieux, une perte au pire.

Ainsi, vous pouvez utiliser la troisième personne pour certaines tâches auxiliaires, comme enlever l'excès de saleté du voisinage du puits. Très bien, cela ajoute peut-être 5% de gain de temps pour le coût d'un ouvrier complet.

Mais comment pouvez-vous utiliser un quatrième homme, sans parler de 11 autres? Si vous insistez vraiment pour les utiliser tous, vous commencerez à avoir des coûts supplémentaires tels que la communication, le temps de permutation, etc. .

Et cela suppose que tous les collaborateurs sont qualifiés . Et si creuser un puits nécessitait une précision supplémentaire et que vous engagiez un intérimaire non formé pour cela? Vous devez leur apprendre pour que vous passiez la première heure à montrer comment bien faire des murs pour qu'ils ne se désagrègent pas et comment obtenir cette forme parfaitement ronde. Ensuite, ils travailleront à 50% de la vitesse de l'homme formé et leur travail ne sera toujours pas parfait, donc le type permanent devra faire les correctifs, perdant du temps de son travail. En réalité, avant que la nouvelle personne ne puisse apporter quoi que ce soit mais retarde, le puits sera prêt. Et cela prendra plus de temps que si l'ouvrier qualifié creuse seul. Vous pouvez toujours utiliser un temp pour ces tâches auxiliaires ou les plus simples (pendant que je fais une pause au milieu, laissez les murs intacts), mais cela fait encore 5, peut-être 10% de gain au mieux. Et si la température atteint le mur, le travailleur qualifié doit réparer tout cela et ce n'est plus du tout un gain.

Et c'est quelque chose d'aussi simple que de balancer une pelle. Le codage est beaucoup plus complexe.

Résumez-le avec quelque chose comme ça:

Il est évident que vous devez former un développeur et 1 mois est un minimum pour les faire fonctionner au niveau de productivité de base s'ils sont qualifiés . Pendant la formation, vous devez investir le temps d'un développeur régulier dans la formation et le travail des intérimaires doit de toute façon être revu, donc ajouter quelqu'un à l'équipe pendant moins de 4 à 6 mois n'est rien d'autre que du gaspillage.

L'autre idée suggérait que vous pourriez être impliqué dans le processus d'embauche. C'est un bon conseil pour réduire le temps d'introduction d'une nouvelle personne dans l'équipe et limiter le nombre d'erreurs dans son code, mais cela nécessitera toujours une formation (une introduction). Donc, un intérimaire, même qualifié, pendant un mois est un gaspillage. Au mieux, vous pouvez les utiliser pour écrire des choses auxiliaires. Comme les tests unitaires ;-)

Si votre manager ne peut pas comprendre une telle comparaison, votre dernière option est de revenir sur le marché du travail.

Ceci s'aventure dans des conseils généraux de développement logiciel ....

1. Si le code que quelqu'un écrit casse quelque chose, ajoutez un test automatisé pour que vous puissiez le voir plus tôt la prochaine fois.

2. Examinez les demandes d'extraction, ne fusionnez rien tant que vous n'êtes pas sûr que rien d'autre ne casse.

3. Les tests font une bonne spécification. Le TDD est un bon moyen de vous assurer que ce que vous obtenez est ce que vous voulez. Donnez à quelqu'un une tâche pour écrire le code dont vous avez besoin (comme illustré par les tests que vous avez déjà écrits).

4. La programmation par les pairs peut être une option. Vous pouvez corriger les choses immédiatement et répondre aux questions au fur et à mesure.

Comment aborder le patron qui ne cesse de recruter des intérimaires pour que je termine quelque chose?

Vous avez déjà. Tout ce que vous pouvez faire est de persévérer pour en parler au patron.

En attendant, il y a une solution, la raison pour laquelle vous devez refaire le travail est que vous avez découvert que c'était trop tard. Vous avez la possibilité de mettre en pratique certaines compétences et d'assumer plus de responsabilités, mais vous ne le faites pas. Ce n'est pas un problème ésotérique, c'est juste une façon de regarder un problème et une méthodologie de résolution. Cela vaut la peine d'être appris.

C'est l'un de ces moments où la microgestion est essentielle. Évaluez la situation dans son ensemble (y compris les gens, ils sont une ressource) et faites un plan de résolution, utilisez efficacement la main-d'œuvre dans ces conditions. C'est la SEULE façon de le faire, vous ne laissez même pas les personnes expérimentées s'écarter de votre plan, elles n'ont pas la vue d'ensemble, vous leur donnez de petites tâches et vérifiez tout ce qu'elles font, elles vous rendent compte à chaque étape.

Le plus important est de comprendre complètement le problème et d'avoir un plan solide. Ensuite, divisez-le en tâches plus simples dans la mesure du possible et ne comptez sur personne pour faire son travail sans supervision.

Si vous pouvez vous en tirer avec des arguments logiques comme les 9 mois pour faire une analogie de bébé, c'est génial mais, d'après mon expérience, cet argument ne fonctionne qu'avec des personnes qui comprennent déjà. Et même lorsqu'elles le font, elles seront souvent suivies de questions sur le nombre optimal de membres de l'équipe.

Ce qui pourrait aider si la logique échoue est de rassembler des données montrant comment le travail est réellement effectué et se concentrer sur le travail des gens qui doit être corrigé. Si vous regroupez ces éléments, vous pouvez afficher un graphique assez spectaculaire de ceux qui ajoutent réellement à la sortie et de ceux qui y contribuent.

Une partie du problème est que les gestionnaires sont sous pression pour livrer et ils ont besoin pour montrer qu'ils font quelque chose pour y arriver. Ne rien faire pourrait les rendre inefficaces et non pertinents. Vous pouvez y contribuer en proposant des modifications que votre responsable peut apporter et qui aideront (meilleures machines, ordinateurs portables, tableaux blancs, un serveur de build, différentes heures, espace de travail isolé, etc.)

Le niveau de compétence des intérimaires dépend probablement du montant que votre manager y investit. Comme ce ne sont que des intérimaires, il ne veut évidemment pas gaspiller trop de fonds. Comme vous le dites, votre patron n'est pas un développeur et suppose probablement qu'un codeur peut coder.

Cependant, si cela augmente votre charge de travail à long terme et que cela affecte votre travail actuel. Vous devez le tirer pour un 1x1 et simplement transmettre vos problèmes et la raison pour laquelle vous ne leur déléguez pas autant de travail et vos soucis pour l'avenir si vous leur déléguez du travail

Vous voulez Assurez-vous de ne pas avoir l'impression que vous avez un essai avec votre patron, mais en même temps, vous devez faire passer le message car il ne comprend pas ce qui se passe dans le développement. Si vous mentionnez simplement que vous seriez heureux de déléguer le travail, mais seulement lorsque vous vous sentez en sécurité.

Je trouve utile de discuter d'un exemple spécifique. Prenons un cas de quelque chose qu'un intérimaire a fait et que vous avez dû réparer. Décrivez le problème sur lequel vous travaillez. Faites une chronologie minutieuse des événements, indiquant quand le temp a été invité à y travailler, combien de temps le temp a travaillé dessus, quand les problèmes ont été découverts, comment les problèmes ont été résolus, et quand le code était prêt ou du moins revenu à utilisable. Comparez avec une estimation de la façon dont cela aurait fonctionné avec une équipe de développement stable. Vous pouvez admettre que vous avez choisi l'exemple, mais que vous avez également une liste de nombreux problèmes où cela s'est produit.

Maintenant, discutez de votre solution, qui semble embaucher un membre permanent du personnel. Combien de temps faudra-t-il pour former cette personne (mais vous ne le faites qu'une fois, pas une fois par intérim), comment les coûts se comparent-ils (comme vous le savez), etc.

Cela ressemble à votre patron / l'entreprise ne comprend pas que vous avez trop de travail à faire. L'embauche d'intérimaires a du sens lorsque la surcharge est temporaire, mais c'est une solution très coûteuse lorsque la surcharge est permanente. Vous devez faire ce cas.

Les autres réponses sont toutes très bonnes. Cependant, je suggérerais une autre approche. S'il s'agit d'un problème récurrent, c'est peut-être, comme votre responsable semble le penser, une indication que votre charge de travail est trop élevée pour que ses attentes soient satisfaites par vous seul.

Vous faites remarquer que sa solution à ce problème ne fonctionne pas, et vous devrez peut-être lui expliquer pourquoi. Les autres réponses couvrent la plupart des arguments que vous pourriez faire valoir à cet égard. Mais si vous voulez voir un changement, la meilleure façon d'accomplir cela est généralement de suggérer votre propre solution alternative.

Peut-être qu'au lieu de continuer à embaucher des intérimaires, il pourrait envisager un ajout permanent à l'équipe. Si vous êtes réellement prêt à déléguer des tâches, mais que vous ne pouvez pas parce que la qualité du code n'est pas à la hauteur, c'est la partie que vous devez corriger. Cependant, si vous voulez que quelqu'un investisse dans l'apprentissage de votre architecture et de votre style de codage, il doit s'attendre à ce que l'investissement soit rentable. Un ajout permanent à l'équipe entraîne des coûts supplémentaires, mais l'amélioration de la qualité de leur contribution et la réduction du besoin de supervision / retouche peuvent facilement se rentabiliser à long terme.

Tests unitaires

Cette réponse suggère que vous devriez écrire des tests unitaires et les faire coder pour les tests. C'est une approche, mais cela vous laisse la tâche d'écrire des tests unitaires. Ce n'est peut-être pas ce que vous voulez. Et pour obtenir les meilleurs résultats, vous devez écrire de bons tests complets et avoir de bons développeurs. Parce que les tests contrôlent le résultat plutôt que le processus. Il est tout à fait possible d'écrire du code moche (difficile à maintenir et à modifier) ​​qui passe les tests.

Une autre approche consiste à changer les choses. Au lieu d'écrire des tests, demandez aux autres développeurs d'écrire les tests. Vous continuez à écrire le code que vous alliez écrire de toute façon. S'il réussit les tests, tant mieux. Si ce n'est pas le cas, vous pouvez alors vous demander pourquoi. Si la raison est que le test est nul (ce qui signifie qu'il ne correspond pas aux exigences réelles), supprimez le test. Chaque fois que vous faites cela, enregistrez cette décision.

Vous pouvez également consulter les tests de réussite pour leur utilité. Encore une fois, s'ils ne sont pas utiles pour codifier les exigences, supprimez-les. Enregistrez la décision.

Cela repose sur le fait qu'il est plus facile de revoir les tests que le code. Il est donc beaucoup plus facile de voir si un développeur peut passer de l'écriture de tests au code que de déterminer si le code du développeur est suffisamment bon à lui seul.

À la fin du mandat du développeur temporaire, rédigez des statistiques sur le nombre de tests utiles ou supprimés. Ce sont alors les informations que vous présentez à votre patron lorsque vous vous opposez à l'embauche de plus d'intérimaires. Incluez le temps qu'il a fallu pour examiner les tests par rapport au temps qu'il aurait fallu pour écrire la suite de tests finale. Si ce nombre est net négatif, alors la société a payé de l'argent pour un «développeur» pour aggraver votre logiciel. Même s'il est net positif, comparez le coût de l'intérim à ce que votre coût aurait été.

D'après mon expérience, les patrons répondent le mieux aux arguments financiers avec des preuves. Sans la preuve, ils peuvent rejeter l'argument. Avec des preuves techniques mais pas financières, ils ne comprendront pas nécessairement les preuves (certains peuvent mais beaucoup ne le feront pas). Alors exprimez toute preuve technique en termes financiers.