Quels sont les moyens d'atténuer les effets du Mois de l'homme mythique?

La loi de Brooks: Ajouter de la main-d'œuvre à un projet logiciel tardif le fait plus tard.

Dans son livre No Silver Bullet - Essence and Accidents of Software Engineering, Frederick Brooks définit le concept du mois de l'homme mythique :

L'hypothèse de Brooks est que les projets de programmation complexes ne peuvent pas être parfaitement divisés en tâches discrètes qui peuvent être travaillées sans communication entre les travailleurs et sans établir un ensemble d' interrelations complexes entre les tâches et les travailleurs qui les exécutent .

Depuis 1982, nous avons certainement progressé et accumulé un peu plus d'expérience pour atténuer ce problème. Quelles sont certaines des solutions que vous avez appliquées avec succès à votre travail pour ajouter des ressources à un projet sans créer plus de problèmes.

Qu'est-ce que le MMM

Je veux d'abord expliquer le contexte de la loi de Brook. Quelle est l'hypothèse qui l'a poussé à le créer en 1975?

Un mois-homme est une unité de travail hypothétique représentant le travail effectué par une personne en un mois; La loi de Brooks dit qu'il est impossible de mesurer le travail utile en hommes-mois.

^{source: https://en.wikipedia.org/wiki/The_Mythical_Man-Month}

À l'époque, des projets de programmation complexes signifieraient de gros systèmes monolithiques. Et Brooks affirme que ceux-ci ne peuvent pas être parfaitement divisés en tâches discrètes qui peuvent être travaillées sans communication entre les développeurs et sans établir un ensemble d'interrelations complexes entre les tâches et les personnes qui les exécutent.

Cela est tout à fait vrai dans les monolithes logiciels hautement cohésifs. Quel que soit le découplage, le gros monolithe exige encore du temps pour que les nouveaux programmeurs se familiarisent avec le monolithe. Et une surcharge de communication accrue qui consommera une quantité toujours croissante de temps disponible.

Mais doit-il vraiment en être ainsi? Faut-il écrire des monolithes et garder les canaux de communication n(n − 1) / 2où se ntrouve le nombre de développeurs?

Nous savons qu'il existe des entreprises où des milliers de développeurs travaillent sur de grands projets ... et cela fonctionne. Il doit donc y avoir quelque chose qui a changé depuis 1975.

Possibilité d'atténuer le MMM

En 2015, PuppetLabs et IT Revolution ont publié les résultats du rapport 2015 State of DevOps . Dans ce rapport, ils se sont concentrés sur la distinction entre les organisations très performantes et les organisations non performantes.

Les organisations hautement performantes présentent des propriétés inattendues. Par exemple, ils ont les meilleures performances d'échéance de projet en développement. Meilleure stabilité opérationnelle et fiabilité des opérations. Ainsi que le meilleur bilan de sécurité et de conformité.

L'une des choses surprenantes mises en évidence dans le rapport est la mesure des déploiements par jour. Mais pas seulement les déploiements par jour, ils ont également mesuré déployer / jour / développeur et quel est l'effet de l'ajout de développeurs dans les organisations hautement performantes par rapport aux non performants.

Voici le graphique de ce rapport -

Alors que les organisations peu performantes s'alignent sur les hypothèses du Mythical Man Month. Les organisations hautement performantes peuvent faire évoluer le nombre de déploiements / jour / dev de manière linéaire avec le nombre de développeurs.

Une excellente présentation à DevOpsDays Londres 2016 par Gene Kim parle de ces résultats.

Comment faire

Tout d'abord, comment devenir une organisation performante? Il y a quelques livres qui en parlent, pas assez d'espace dans cette réponse, donc je vais juste les lier.

• Bon à grand: pourquoi certaines entreprises font le saut ... et d'autres pas par Jim Collins
• The High-Velocity Edge: Comment les leaders du marché tirent parti de l'excellence opérationnelle pour battre la concurrence par Steven Spear
• La nouvelle économie pour l'industrie, le gouvernement et l'éducation par W. Edwards Deming

Pour les organisations logicielles et informatiques, l'un des facteurs critiques pour devenir une organisation hautement performante est: se concentrer sur la qualité et la vitesse .

Par exemple, Ward Cunningham explique la dette technique comme toutes les choses que nous avons laissées non fixées. Ceci est accepté par la direction, car il est toujours accompagné d'une promesse qu'il sera corrigé quand le temps le permettra.

Il n'y a jamais assez de temps et la dette technique ne fait qu'empirer.

Quelles sont ces choses qui font augmenter la dette technique?

• code hérité
• configuration manuelle des environnements
• test manuel
• déploiements manuels

Le code hérité Tel que défini dans Travailler efficacement avec le code hérité de Michael Feathers est tout code qui n'a pas de test automatisé.

Chaque fois que des raccourcis sont utilisés pour mettre le code en production; les opérations sont grevées du maintien de cette dette pour toujours. Ensuite, le processus de déploiement devient de plus en plus long.

Gene raconte une histoire dans sa présentation sur une entreprise qui a des déploiements de six semaines. Cela impliquait des dizaines de milliers de mesures fastidieuses extrêmement sujettes aux erreurs, liant 400 personnes, et ils le feraient quatre fois par an.

L'un des principes de DevOps est que la fiabilité vient de l'exécution plus fréquente de petits déploiements.

Exemple

• Jon Jenkins à Velocity 2011 : Amazon fait 15 000 déploiements / jour
• Ken Exner au AWS Summit 2015 : Amazon effectue 136 000 déploiements / jour

Ces deux présentations montrent tout ce qu'Amazon a fait pour réduire le temps nécessaire au déploiement du code en production.

Selon Gene, la seule chose qui change au fil du temps dans ces organisations très performantes est le nombre de développeurs. Donc, à partir de l'exemple d'Amazon, on pourrait dire qu'en quatre ans, ils ont multiplié leurs déploiements dix fois simplement en ajoutant plus de personnes.

Cela signifie que dans certaines conditions, avec la bonne architecture, les bonnes pratiques techniques, les bonnes normes culturelles, la productivité des développeurs peut évoluer à mesure que le nombre de développeurs augmente. Et DevOps est définitivement au milieu de tout cela.

Ce que j'ai fait (et ce n'est que subjectif) est le suivant:

Quand un manager qui pense à une date d'échéance souhaite ajouter des personnes dans mon équipe pour réduire le temps nécessaire et semble sous MMM, je discute d'abord avec lui des raisons pour lesquelles cela pourrait être mauvais. Mon analogie préférée est de leur rappeler que si une femme peut avoir un bébé en neuf mois, neuf femmes n'auront pas un bébé en un mois, mais elles auront neuf bébés en neuf mois. Le temps n'est pas coupé, juste le traitement parallèle est meilleur.

Lorsque la décision est imposée à notre équipe, nous essayons généralement de diviser davantage certaines tâches, et lorsque cela n'est pas possible, nous nous appuyons généralement sur la programmation par paires , où un programmeur est responsable de la frappe et l'autre dicte le code (et change périodiquement). ).

L'écriture de code elle-même est plus lente, mais il y a moins de fautes de frappe et de bugs lors des tests en raison de la révision inévitable effectuée lors de l'écriture. Je pense que la qualité globale du code est également un peu meilleure, mais je n'ai pas de mesures pour soutenir cette affirmation.

S'exprimant exclusivement du point de vue de CI, l'augmentation du nombre de développeurs travaillant sur un projet se traduit généralement par plus de personnes travaillant dans la même branche.

Les systèmes CI traditionnels ont un problème d'évolutivité à cet égard: la probabilité de ruptures / régressions / blocages augmente, ce qui ralentit la vitesse d'intégration et invite les petites équipes à se séparer et à passer aux branches enfants (c.-à-d. De nouveaux ralentissements). Voir Comment l'intégration continue peut-elle évoluer pour de très grands projets / équipes? . Cela joue le long du concept du mois de l'homme mythique.

La solution que je suggère dans ma réponse à cette question, un système de CI hautement évolutif permettrait la migration vers un véritable CI - intégration basée sur une seule branche / tronc pour des équipes entières (même avec des tailles énormes).

Avec tout le monde sur la même page, en utilisant les mêmes outils / processus automatisés et la grande majorité des vérifications d'AQ automatisées à l'intérieur du système CI lui-même, il devient beaucoup plus facile de changer de rôle et de se concentrer entre les membres de l'équipe. L'ensemble du processus de développement devient plus fluide, plus prévisible, plus détendu.

Amener de nouvelles personnes à bord dans un tel environnement, les rendre productives simplement en déchargeant des tâches moins difficiles des membres de l'équipe plus expérimentés qui peuvent ensuite assumer des tâches plus difficiles est donc plus facile.

Tout cela peut être vu, je crois, comme apaisant les effets du concept du Mois de l'homme mythique.