Qu'est-il arrivé au motif «Équipe chirurgicale» de «The Mythical Man-Month»?

Il y a des années, lorsque j'ai lu Le mois mythique de l'homme, j'ai trouvé beaucoup de choses que je connaissais déjà d'autres sources. Cependant, malgré le fait que le livre date de 1975, il y avait également de nouvelles choses.

L'équipe chirurgicale

Mills propose que chaque segment d'un travail important soit abordé par une équipe, mais que l'équipe soit organisée comme une équipe chirurgicale plutôt que comme une équipe de charcutier. Autrement dit, au lieu que chaque membre coupe le problème, l’un fait la coupe et les autres lui apportent tout l’appui nécessaire pour améliorer son efficacité et sa productivité.

C'est un modèle très intéressant pour organiser une équipe de développement logiciel, mais je ne l'ai jamais trouvé décrit dans aucun autre livre de génie logiciel, même mentionné nulle part.

Pourquoi donc?

• Est-ce que "l'équipe chirurgicale" était encore inhabituelle à l'époque?
• Ou a-t-il été essayé et a échoué?
  • Si oui, comment cela a-t-il échoué?
  • Sinon, pourquoi ne voyons-nous pas ce modèle implémenté dans les projets logiciels actuels?

"The Mythical Man-Month" est sorti l'année où j'ai commencé l'université et était, pour utiliser le langage courant, UUUGE! :-) Ce que vous devez comprendre, c'est la différence entre la façon dont le logiciel a été développé, THEN et NOW. Back In The Day (tm) à peu près tout le codage a été effectué sur papier d’abord, puis sur des cartes perforées (vous l’avez deviné), puis a été lu, compilé, lié, exécuté, les résultats obtenus et le processus répété. Le temps de calcul était coûteuxet des ressources limitées et vous ne vouliez pas le gaspiller. Idem et de même espace disque, temps de lecteur de bande, etc., blah. Perdre du temps processeur parfaitement correct sur une compilation, ce qui entraînait des erreurs (choc et horreur!) Était ... bien, une perte de temps CPU parfaitement bon. Et c’était en 1975. À l’époque où Fred Brooks développait ses idées, c’est-à-dire au milieu des années 1960, le temps de calcul était encore plus long.cher, mémoire / disque / tout ce qui était encore PLUS limité, etc., etc. L’idée de l’équipe chirurgicale était de faire en sorte que le développeur One Super Great Rockstar n’ait pas à perdre son temps à des tâches banales telles que le code de vérification de bureau, la saisie au clavier, soumettre des travaux, attendre (parfois pendant des heures) les résultats. Rockstar Dude Developer Man devait être WRITING CODE. Sa légion de groupies / employés / développeurs juniors était supposée s'occuper de choses banales.

Le problème était que deux ans après la publication du livre de Brooks, les idées de base de The Surgical Team s'effondraient:

1. Les terminaux à tube cathodique et les fichiers sur disque ont commencé à remplacer les combinaisons de touches et les jeux de cartes. Le temps de calcul est devenu moins coûteux, plusieurs ordinateurs sont devenus disponibles et le temps de traitement des tâches a considérablement diminué. Quand je suis arrivé au collège (université de Miami, Oxford, Ohio, promotion de 1979, merci d'avoir posé la question), bonnele temps de traitement des tâches était d'environ une heure. Pendant les finales, quatre heures, peut-être parfois six. (Nous avons concouru pour gagner du temps d’ordinateur avec un groupe d’entreprises commerciales et d’universités - et les utilisateurs commerciaux ont obtenu la première priorité). Au cours de ma dernière année, à ce moment-là, Miami était sorti de son arrangement "d'ordinateur partagé", avait installé son propre IBM 370/145 sur le campus et avait une belle mini HP sur laquelle je travaillais, qui agissait comme une station RJE sur laquelle nous pouvions tourner. emplois autour en cinq minutes ou moins. Il valait maintenant la peine de taper votre code sur HP, de l’envoyer de l’ordinateur HP à l’ordinateur central, de tourner votre pouce / de fumer une cigarette et de récupérer votre sortie bien avant que vous puissiez finir de vérifier votre code.

2. L’équipe chirurgicale a pour principe de base l’idée que vous (ou "la direction", Dieu nous aidez tous) pouvez identifier The Duck. En fait, je doute que ce soit possible. Il existe des développeurs rockstar, tout le monde le sait - des études ont montré des différences de productivité allant jusqu'à 2 000% entre les meilleurs et les plus mauvais développeurs - mais en identifiant cette personne sans lui demander d'écrire du code sur une longue périodeest probablement impossible. Le seul moyen de savoir si un développeur est rockstar est de lui demander de développer du code - mais s'ils ne sont pas le développeur de Rockstar Surgical Dude, ils effectueront des tâches intéressantes, comme vérifier son code, le saisir à l'aide de cartes, et envoyer des boîtes de cartes perforées au service des offres d'emploi, puis attendre les résultats pour pouvoir les envoyer à M. Rockstar Surgical Developer Dude au lieu d'apprendre à coder de la seule façon qui fonctionne réellement - en écrivant du code, du code de débogage, Back In The Day (tm), il n’y avait pas de concours de programmation, pas de débordement de pile, vous n’aviez pas de PC sur lequel vous pouviez écrire du code quand vous en aviez envie, il n'y avait pas d'algorithmes pour les livres Idiots - la seule façon d'apprendre à programmer était d'aller à l'école et de se spécialiser dans quelque chose où il fallait faire un peu de programmation. Mais la programmationen soi, cela n'a pas été pris au sérieux et on a supposé que c'était quelque chose que les gens ne voulaient pas faire . Dans mon premier cours universitaire (SAN151 - Introduction à l’analyse des systèmes, Dr. Tom Schaber - merci Tom :-), l’instructeur nous a dit que "... nous devions simplement faire face au fait que nous devions passer quelques années en tant que programmeurs avant que nous puissions devenir analystes de systèmes ". "Deux ans?", Pensai-je. "JE SUIS OBTENU SEULEMENT DE FAIRE CELA DEUX ANS?!?" J'étais sérieusement dégouté. Heureusement, il s'est trompé et je code depuis presque pas mal. :-)

3. L'équipe chirurgicale suppose que les programmeurs sont une ressource relativement rare. Cela a effectivement pris quelques années de plus, mais avec l'avènement des ordinateurs personnels au début des années 80, tout programmeur entrait en jeu. Le prix des ordinateurs a commencé à baisser, le prix des outils de développement a commencé à baisser. salut Turbo Pascal - ce n’était pas beaucoup selon les normes d’aujourd’hui, mais c’était à l’époque un IDE complet de Pascal pour environ 40 dollars, ce qui était absolument dingue! Maintenant, tout le monde peut se lancer dans la programmation - si vous pouviez vous permettre un ordinateur, et quand IBM a décidé de mettre le PCjr (ouais, mon premier PC était l’une des plus grosses erreurs d’IBM :-) vendu environ 500 $ pour se débarrasser de ces dindes, - Les geeks à bottes ont omis de payer leur loyer pendant un mois ("Ouais, euh, je sais, mais je, euh ... me suis cassé la peau et j'ai dû subir une opération chirurgicale et .. . euh ... ouais, la semaine prochaine, pas de problème, merci, mec ...) et les ai aspirés à des prix imbattables. Ensuite, nous avons dépensé plus que ce que nous avons payé pour l’ordinateur en add-ons pour le rendre utilisable. ("Ouais mec, la semaine prochaine, c'est sûr, probablement ..." :-).

Ce qui me rend vraiment triste, c’est que même aujourd’hui, si vous demandez aux gens s’ils ont déjà lu "Le mois mythique" ou si l’on en comprend la principale leçon ("Ajouter des ressources à un projet en retard le rend plus tard"), ils vous donnent un blanc. stare - et commettez ensuite les mêmes erreurs que celles qui ont été commises il y a bien des années lors du développement d'OS / 360. Tout ce qui est vieux est nouveau à nouveau ...: -}

Certains aspects de ce concept sont parfois mis en œuvre aujourd'hui, d'autres sont évités .

Garder les équipes de petite taille est l’une des caractéristiques de base des méthodes agiles, mais est également pratiqué en dehors de la méthode agile.

Les équipes interfonctionnelles sont également un élément essentiel de Agile, mais sont également communes en dehors de Agile.

Le rôle du commis aux programmes est en grande partie contenu dans des systèmes informatisés tels que les systèmes de contrôle de version, les systèmes de gestion de configuration logicielle, les systèmes de gestion de changement, les systèmes de gestion de documents, les wikis, les systèmes de construction continue avec des référentiels d'artefacts, etc. Je veux dire, pouvez-vous vraiment imaginer payer un employé à temps plein pour imprimer le code source, l’indexer et le classer manuellement?

De même, le rôle d'administrateur système (ne faisant pas partie de l'équipe chirurgicale de Mills, mais faisant partie d'une équipe interfonctionnelle typique des dernières années) est obsolète par des concepts tels que DevOps (absorbant le rôle de Sysadmin dans celui d'ingénieur logiciel). , Platform-as-a-Service, Infrastructure-as-a-Service et Utility Computing (le rôle de Sysadmin est "le problème de quelqu'un d'autre"), ou Infrastructure-as-Code (transformant l'administration du système en génie logiciel).

L’un des aspects que nous essayons d’éviter aujourd’hui est qu’au plus deux personnes comprennent le système. Seul le chirurgien est assuré de bien comprendre le système, que le copilote puisse le faire ou non. Cela donne un facteur de bus compris entre 1 et 2. Si le chirurgien tombe malade, le projet est mort. Période. La réponse agile à cette question est la propriété collective du code, qui est l' exact opposé de ce modèle: personne n'est singulièrement responsable d' une partie du système. Au lieu de cela, tout le monde est responsable de tout en tant que groupe .

Enfin, certaines hypothèses formulées dans ce concept sont dépassées. Par exemple, même si cela n’est pas indiqué explicitement, l’équipe est configurée de manière à ce qu’une seule personne de l’équipe (le chirurgien) dispose d’un ordinateur. Cela tient évidemment au fait qu’au moment de la rédaction de l’article, même l’idée selon laquelle une équipe entière disposerait d’un ordinateur, sans parler d’une personne de l’équipe, n’allait pas de soi. (Même en 1980, lors de la sortie de Smalltalk, l'un des facteurs qui ont contribué à son échec était le fait que le système était configuré de telle sorte que chaque développeur et chaque utilisateur disposait de son propre ordinateur, ce qui était totalement impensable à l'époque.)

Donc, en bref: je ne pense pas que le concept ait été mis en œuvre exactement tel qu'il a été décrit, mais certains de ses aspects sont définitivement mis en œuvre, certains aspects sont considérés comme indésirables et activement évités, certains sont obsolètes et certains sont probablement de bonnes idées ™, mais personne ne le fait.

Auparavant, une formation universitaire était unique et les ingénieurs figuraient parmi les rares élus. Les ordinateurs coûtaient cher et les équipes travaillaient sur des projets avec un ROI défini. Celles-ci n'étaient pas très communes.

Il s’agissait de micro-ordinateurs, d’un programme de premier cycle omniprésent et de systèmes informatiques qui n’avaient même pas besoin de diplômes universitaires pour progresser. De plus, ce qui s'est passé était une économie en mutation et une augmentation du coût de la main-d'œuvre.

L’économie d’un ratio de support technique de 8: 2 n’a plus de sens. Les ingénieurs doivent être leur propre soutien. Un être humain moderne ayant une éducation et des compétences suffisantes pour être rattaché efficacement à une équipe de développement est trop coûteux pour ne pas développer lui-même son développement.

(Un terme économique apparenté est "la maladie des coûts du secteur des services".)

Cela ressemble beaucoup à la programmation Mob:

L'ensemble du groupe (QA, développeurs et même Product Owner si nécessaire) travaille en même temps dans le même problème. Pas de stand up, haute communication, directement déployée en live.

De http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/

Le concept de base de la programmation par mob est simple: toute l'équipe travaille en équipe sur une tâche à la fois. C'est-à-dire: une équipe - un clavier (actif) - un écran (projecteur bien sûr). C'est comme faire une programmation par paire complète.

Voyez-le en action ici: https://www.youtube.com/watch?v=dVqUcNKVbYg

Ce modèle d'équipe est à nouveau mentionné dans le document Rapid Development - Taming Wild Software Schedules par Steve McConnell à la page 305. Il est appelé «équipe de programmeurs en chef».

Ce modèle découle du génie de l'équipe et de la limitation des ressources informatiques. Il est tombé en disgrâce, car le génie est rare et, avec des ordinateurs omniprésents et un contrôle de version distribué, nous avons de la place pour de nombreuses mains à la table d'opération.

Autres références:

Baker, F. Terry. "Gestion en chef de la programmation de production par l'équipe de programmeurs", IBM Systems Journal, vol. 11, non. 1, 1972, pages 56-73.

Baker, F. Terry et Harlan D. Mills. "Équipes de programmeurs en chef." Datamation, volume 19, numéro 12 (décembre 1973), p. 58-61.

Je pense que la plupart des petites équipes auto-organisées auront de toute façon tendance à s’inscrire dans un modèle d’équipe chirurgicale de facto.

Les deux dernières équipes auxquelles j'ai participé ont tendance à être composées de trois ou quatre personnes, généralement un senior (chirurgien), un intermédiaire (co-pilote) et quelques juniors / spécialistes. Certains des rôles de l’équipe chirurgicale mentionnés par Brooks aujourd’hui sont remplis par des maîtres et administrateurs système Scrum ou des fournisseurs de cloud. Rappelez-vous que le contrôle de la source n’existait pratiquement pas à l’époque, sans parler de quelque chose d’aussi puissant que git.

Pensez à la règle des deux pizzas de Bezos. C'est votre équipe chirurgicale auto-organisatrice, juste là.

Il y avait un article de HP qui suggérait quelque chose de similaire:

• Chaque ingénieur logiciel nécessiterait plusieurs gestionnaires et plusieurs personnes de soutien.
• Il devrait y avoir un rédacteur technique, un testeur, un responsable de la construction et un outilleur pour chaque ingénieur.

Le journal était en pré-web, et a été amené de temps en temps comme drôle. Chaque année, le commentaire passait de "si ridicule que c'est drôle" à "peut-être devrions-nous faire cela".

Les tests réels sont notoirement difficiles à concevoir, il reste donc probablement une opinion. Il peut exister des enquêtes sur les projets et leurs taux d’achèvement.

Je me demande à quel point le besoin d’une équipe chirurgicale est devenu superflu en raison de la montée en puissance d’Internet, d’ environnements de développement intégrés et de kits de développement logiciel , qui peut prendre en charge une grande partie des fonctionnalités attribuées par Fred Brooks à l’équipe chirurgicale, notamment:

• Chirurgien: un programmeur
• Co-pilote: programmeurs en binôme , collègues, communautés en ligne telles que StackExchange ou IRC
• Administrateur: rôle généralement joué par un chef de projet logiciel
• Editeur: IDE intégrant des générateurs de documentation comme Javadoc ou Doxygen; documentation des kits de développement logiciel
• Secrétaire: client de messagerie, outils de gestion de projet tels que les suiveurs de problèmes et les demandes d'extraction, les salles de discussion et les listes de diffusion
• Responsable de programme: IDE stockant des informations sur la conception du projet, avec la possibilité supplémentaire de refactoriser le code; documentation et exemples de kits de développement logiciel
• Toolsmith: toute la communauté open source
• Testeur: immédiatement, suites de tests et bibliothèques de tests. Mais bien sûr, un processus d'assurance qualité séparé est nécessaire pour le code de production.
• Juriste linguistique: documentation en ligne, StackExchange

Je pense que vous devez regarder la prémisse du Mois de l'homme mythique. Embaucher plus de programmeurs ne fait qu'aggraver un projet logiciel problématique / en retard. Le problème est lié à la communication et à la mise au point des programmeurs nouvellement ajoutés (cela prend du temps par rapport au développement existant), de la technologie et parfois du domaine lui-même.

Un programmeur bien pris en charge élimine une grande partie du temps de communication et de la coordination. Supposons que vous engagiez un consultant pour Technology X. Au lieu de renseigner suffisamment le consultant sur le projet pour qu'il puisse effectuer tous les codages dans cette zone, il conseille simplement le développeur existant au point de lui permettre de construire quelque chose. avec un peu de supervision.

Une des raisons pour lesquelles vous ne voyez pas grand-chose à cela est que la plupart des logiciels sont écrits par une seule personne. Les équipes se répartissent le travail et tout le monde va et fait sa chose. La programmation en binôme, les critiques et tout ce qui sent la microgestion est mal vue. Beaucoup ne voient pas la programmation comme un sport d'équipe. Une personne résout un problème donné en tenant compte des contraintes globales.

Je dirais que plus nous séparons la conception, la mise en œuvre, les tests, la documentation, la construction, le déploiement, les opérations, etc. en des rôles uniques assumés par des spécialistes, plus nous suivons la philosophie de "l'équipe chirurgicale" (bien que peut-être pas de la manière décrite ).

D'après mon expérience, la philosophie de devOps selon laquelle chaque personne devrait être capable de chaque tâche est un retour au modèle de l'abattage sélectif (pour ne pas dire que c'est mauvais, c'est juste différent).

En tant que programmeur occupant souvent les rôles de DevOps et de Build Master, j’ai eu l’impression que je me retrouvais souvent dans cette position d’être l’équipe chirurgicale. En tant que maître de la construction, j'avais une vue d'ensemble du code complet et j'étais la première ligne lorsque celle-ci échouait. Souvent, je voudrais juste réparer moi-même.
C’était souvent moi qui écrivais ces systèmes de métriques et mesurais les points chauds dans le code, des pièces qui échouaient plus souvent, qui attiraient le plus de rapports de bogues, etc. kink qui a causé le problème et proposé des solutions et des changements architecturaux pour résoudre ce problème.

En tant que DevOps, j'automatisais d'énormes quantités de processus et de frais généraux. Je recherchais des technologies et des outils qui simplifieraient la vie de l’équipe, de l’ensemble du groupe, des développeurs aux opérations de contrôle d’assurance qualité jusqu’à la gestion. Mon rôle était de comprendre le processus, oui; mais en gardant les yeux rivés sur l'équipe (les humains) utilisant (souffrant) ce processus, j'ai pu le résumer de manière à le rendre complètement transparent tout en obtenant une bande de données utiles pour obtenir une vue objective de ce processus. "grande image" toujours insaisissable.

C'est une position ingrate à avoir et probablement la raison pour laquelle on l'évite autant. Je sais que j'ai bien fait mon travail quand personne n'a remarqué ce processus, quand personne n'a pensé au pipeline de construction. Alors oui, une machine bien huilée est vite tenue pour acquise. Mais je savais, en fait, avoir mesuré l'impact multiplicatif que ce travail peut avoir sur la productivité d'une équipe et l'investissement en vaut la peine.

Donc, oui, je pense que ce rôle est encore très vivant aujourd'hui, même s'il est vrai qu'il a évolué à partir de ce qu'il était à l'époque.