Qu'est-il arrivé au modèle "Équipe chirurgicale" du "Mois de l'homme mythique"?
Il y a des années, quand j'ai lu Le Mois de l'homme mythique, j'ai trouvé beaucoup de choses que je connaissais déjà d'autres sources. Cependant, il y avait aussi de nouvelles choses là-dedans, bien que le livre date de 1975. L'un d'eux était:
Mills propose que chaque segment d'un gros travail soit abordé en équipe, mais que l'équipe soit organisée comme une équipe chirurgicale plutôt que comme une équipe de charcuterie. Autrement dit, au lieu que chaque membre coupe le problème, l'un fait la coupe et les autres lui apportent tout le soutien qui améliorera 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 pas mentionné nulle part.
Pourquoi donc?
- "L'équipe chirurgicale" était-elle encore inhabituelle à l'époque?
- Ou, a-t-il été essayé et échoué?
- Si oui, comment a-t-il échoué?
- Sinon, pourquoi ne voyons-nous pas ce modèle implémenté dans les projets logiciels d'aujourd'hui?
"The Mythical Man-Month" est sorti l'année où j'ai commencé l'université et était, pour utiliser la langue vernaculaire actuelle, UUUGE! :-) Ce que vous devez comprendre, c'est la différence dans la façon dont le logiciel a été développé ALORS vs MAINTENANT. Back In The Day (tm) à peu près tout le codage a été fait sur papier d'abord, puis a été tapé sur (vous l'avez deviné) des cartes perforées, puis a été lu, compilé, lié, exécuté, les résultats ont été obtenus et le processus a été répété. Le temps CPU était une ressource coûteuse et limitée et vous ne vouliez pas la gaspiller. Idem et également l'espace disque, le temps du lecteur de bande, etc., blah. Perdre du temps CPU parfaitement bon sur une compilation qui a entraîné des (choc et horreur!) Erreurs était ... eh bien, une perte de temps CPU parfaitement bon. Et c'était en 1975. Au moment où Fred Brooks développait ses idées, qui était du milieu à la fin des années 1960, le temps CPU était même plus plus cher , mémoire/disque/tout ce qui était encore PLUS limité, etc., etc. L'idée derrière l'équipe chirurgicale était de faire en sorte que le développeur One Super Great Rockstar n'ait pas à perdre son temps sur des tâches banales comme la vérification du code de bureau, la frappe au clavier, la soumission emplois, attendant (parfois pendant des heures) les résultats. Rockstar Dude Developer Man devait être EN ÉCRITURE. Sa légion de groupies/commis/développeurs juniors était censée faire le truc banal.
Le problème était que dans les 2 ans suivant la publication du livre de Brooks, les idées de base de l'équipe chirurgicale étaient en train de s'effondrer:
Les terminaux CRT et les fichiers de disques ont commencé à remplacer les claviers numériques et les jeux de cartes. Le temps consacré aux ordinateurs est devenu moins cher, plusieurs ordinateurs sont devenus disponibles et les délais d'exécution ont chuté de façon spectaculaire. Quand je suis arrivé à l'université (Université de Miami, Oxford, Ohio, classe de 79, merci de me le demander) bon la rotation du travail était d'environ une heure. Pendant la semaine des finales - quatre heures, peut-être, parfois six. (Nous avons concouru pour le temps CPU avec un tas de sociétés commerciales et d'universités - et les utilisateurs commerciaux ont eu la priorité). Au cours de ma dernière année, à ce moment-là, Miami était sorti de son arrangement "ordinateur partagé", avait installé son propre IBM 370/145 sur le campus et avait un Nice HP mini sur lequel je travaillais qui agissait comme une station RJE que nous pouvions transformer en ordinateur central travaux autour en cinq minutes ou moins. Il valait maintenant la peine de frapper votre code sur le HP, de l'envoyer du HP au mainframe, de tourner les pouces/de fumer une cigarette et de récupérer votre sortie bien avant de pouvoir vérifier votre code sur le bureau.
L'équipe chirurgicale a comme prémisse de base l'idée que vous (ou "la direction", Dieu nous aide tous) pouvez identifier The Rockstar Surgical Developer Dude. En fait, je doute que ce soit possible. Il y a développeurs de rockstar, tout le monde le sait - des études ont montré des différences de productivité entre les meilleurs et les pires développeurs allant jusqu'à 2000% - mais en identifiant cette personne sans leur faire écrire du code sur une longue période est très probablement impossible. La seule façon de savoir si quelqu'un est un développeur Rockstar est de lui faire développer du code - mais s'il n'est PAS le développeur Rockstar Surgical, il fera des choses passionnantes comme vérifier son code sur le bureau, le taper sur des cartes et schlepping des boîtes de cartes perforées jusqu'au service de saisie des emplois, puis attend les résultats afin qu'ils puissent les renvoyer à M. Rockstar Surgical Developer Dude au lieu d'apprendre à coder de la seule manière qui fonctionne vraiment - en écrivant du code, en déboguant du code, et etc. Back In The Day (tm), il n'y avait pas de concours de programmation, il n'y avait pas de dépassement 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 d'idiots - le la seule façon d'apprendre la programmation était d'aller à l'école et de se spécialiser dans quelque chose où il fallait faire un peu de programmation. Mais la programmation en soi n'a pas été prise 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 juste faire face au fait que nous devions quelques années en tant que programmeurs avant de devenir analystes de systèmes ". "Deux ans?", Ai-je pensé. "JE NE LE FAIS QUE POUR DEUX ANS?!?". J'étais sérieusement déçu. Heureusement, il avait tort et j'ai codé à peu près depuis. :-)
L'équipe chirurgicale suppose que les programmeurs sont une ressource relativement rare. Cela a en fait pris quelques années de plus, mais avec l'avènement des PC au début des années 80, la programmation est devenue quelque chose dans laquelle tout geek pouvait s'impliquer. Le prix des ordinateurs a commencé à baisser, le prix des outils de développement a commencé à baisser, et c'était tout grêle Turbo Pascal - selon les normes d'aujourd'hui ce n'était pas grand-chose mais à l'époque c'était un Pascal complet IDE pour environ 40 dollars, ce qui était absolument fou! Maintenant, TOUT LE MONDE pouvait entrer dans la programmation - si vous pouvait se permettre un ordinateur, et quand IBM a décidé de mettre le PCjr (oui, mon premier PC était l'une des plus grosses erreurs d'IBM :-) en vente pour environ 500 $ pour se débarrasser de ces dindes, les geeks à court d'argent partout ont sauté leurs paiements de loyer pour un mois ("Ouais, euh, je sais, mais j'ai, euh ... cassé mon uuvula et j'ai dû me faire opérer et ... euh ... ouais, la semaine prochaine, pas de problème, merci, mec ...) et les a sucés à des prix défiant toute concurrence. Ensuite, nous avons dépensé plus que ce que nous avons payé pour l'ordinateur sur des modules complémentaires 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 de l'homme" ou si vous comprenez sa leçon principale ("Ajouter des ressources à un projet tardif le fait plus tard"), ils vous donnent un blanc regarder - puis procéder aux mêmes erreurs que celles qui ont été commises Il y a toutes ces années lors du développement d'OS/360. Tout ce qui est ancien est nouveau à nouveau ...: -}
Il y a certains aspects de ce concept qui sont parfois mis en œuvre aujourd'hui, il y a d'autres aspects qui sont évités .
Garder des équipes petites est l'une des caractéristiques de base des méthodes Agile, mais elle est également pratiquée en dehors d'Agile.
Les équipes interfonctionnelles sont également un aliment de base d'Agile, mais également en dehors d'Agile.
Le rôle du responsable de programme est largement englobé par les systèmes informatiques tels que les systèmes de contrôle de version, les systèmes de gestion de la configuration logicielle, les systèmes de gestion du changement, les systèmes de gestion des documents, les wikis, les systèmes de construction continue avec 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'un 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 le rôle d'ingénieur logiciel). , Platform-as-a-Service, Infrastructure-as-a-Service et Utility Computing (faisant du rôle de Sysadmin "le problème de quelqu'un d'autre"), ou Infrastructure-as-Code (transformant l'administration système en génie logiciel).
Un des aspects que nous essayons d'éviter aujourd'hui est que au plus deux personnes comprennent le système. Seul le chirurgien est assuré de bien comprendre le système, le copilote peut 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 à cela est la propriété du code collectif, qui est exactement l'opposé de ce modèle: personne est singulièrement responsable de toute partie du système. Au lieu de cela, tout le monde est responsable de tout en tant que groupe.
Enfin, certaines hypothèses intégrées à ce concept sont dépassées. Par exemple, même si cela n'est pas indiqué explicitement, l'équipe est constituée de manière à ce qu'une seule personne de l'équipe (le chirurgien) ait réellement un ordinateur. C'est, bien sûr, parce qu'au moment où l'article a été écrit, même l'idée qu'une équipe entière aurait un ordinateur pour elle-même, sans parler d'une seule personne dans l'équipe, était un tronçon. (Même en 1980, lorsque Smalltalk est sorti, l'une des choses qui a contribué à son échec était le fait que le système était configuré de telle sorte que chaque développeur et chaque utilisateur avait son propre ordinateur - complètement impensable à l'époque.)
Donc, en bref: je ne pense pas que le concept ait été mis en œuvre exactement comme décrit, mais certains aspects de celui-ci sont mis en œuvre, certains aspects sont vus 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, les études collégiales étaient quelque chose d'unique et les ingénieurs faisaient partie des rares élus. Les ordinateurs étaient chers et les équipes travaillaient sur des projets avec un ROI d'entreprise défini. Ce n'était pas très courant.
Ce qui s'est passé, ce sont des micro-ordinateurs, une éducation de premier cycle omniprésente et des systèmes informatiques qui n'ont même pas besoin de diplômes universitaires pour progresser. En outre, ce qui s'est produit a été l'évolution de l'économie et l'augmentation du coût de la main-d'œuvre.
L'économie d'un rapport 8: 2 support: ingénieur n'a plus de sens. Les ingénieurs doivent être leur propre support. Un être humain moderne avec une éducation et des compétences suffisantes pour être efficace attaché à une équipe de développement coûte trop cher pour ne pas faire son propre développement.
(Un terme économique connexe est "la maladie des coûts du secteur des services".)
Ce modèle me ressemble beaucoup à la programmation Mob:
L'ensemble du groupe (QA, développeurs et même Product Owner si besoin) travaille en même temps sur le même problème. Pas de stand up, communication élevée, directement déployée en direct.
De http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
Le concept de base de la programmation 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 de la programmation en équipe complète.
Voyez-le en action ici: https://www.youtube.com/watch?v=dVqUcNKVbYg
Ce modèle d'équipe est à nouveau mentionné dans Rapid Development - Taming Wild Software Schedules de Steve McConnell à la page 305. Là, il est appelé l'équipe du chef programmeur.
Ce modèle est né du fait qu'il y avait un génie dans l'équipe et que les ressources informatiques étaient limitées. Il est tombé en disgrâce parce que 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. "Chef de l'équipe de programmation, gestion de la programmation de la production", IBM Systems Journal, vol. 11, non. 1, 1972, p. 56-73.
Baker, F. Terry et Harlan D. Mills. "Chief Programmer Teams." Datamation, volume 19, numéro 12 (décembre 1973), p. 58-61.
Je suppose que la plupart des petites équipes auto-organisées auront de toute façon tendance à s'installer dans un modèle d'équipe chirurgicale de facto.
Les deux dernières équipes dans lesquelles je faisais partie étaient généralement composées de trois ou quatre personnes, généralement un senior (chirurgien), un intermédiaire (copilote) et quelques juniors/spécialistes. Certains des rôles dans l'équipe chirurgicale mentionnés par Brooks de nos jours sont remplis par des maîtres Scrum et des administrateurs système ou des fournisseurs de cloud. N'oubliez pas que le contrôle des sources existait à peine à l'époque, sans parler de quelque chose d'aussi puissant que Git.
Pensez à la règle des deux pizzas de Bezos. Voilà votre équipe chirurgicale auto-organisée.
Il y avait un article de HP qui proposait quelque chose de similaire:
- Chaque ingénieur logiciel aurait besoin de plusieurs gestionnaires et de plusieurs personnes de support.
- Il devrait y avoir un rédacteur technique, un testeur, un gestionnaire de construction et un fabricant d'outils pour chaque ingénieur.
Le journal était en pré-web et a été présenté de temps en temps comme drôle. Chaque année, il a été évoqué, le commentaire passait un peu plus de "tellement ridicule, c'est drôle" à "peut-être que nous devrions faire ça".
Les tests réels sont notoirement difficiles à concevoir, donc cela reste probablement une opinion. Il pourrait exister des enquêtes sur les projets et leurs taux d'achèvement.
Je me demande quelle part du besoin d'une équipe chirurgicale est devenue superflue à cause de l'essor d'Internet, environnements de développement intégrés et kits de développement logiciel , ce qui peut prendre beaucoup des fonctionnalités que Fred Brooks a attribuées à l'équipe chirurgicale, notamment:
- Chirurgien: un programmeur
- Copilote: paires de programmeurs , collègues, communautés en ligne telles que StackExchange ou IRC
- Administrateur: rôle généralement joué par un logiciel chef de projet
- 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 trackers de problèmes et les demandes de tirage, les salons de discussion de l'entreprise et les listes de diffusion
- Commis de programme: IDE stockage d'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: sur une base immédiate, suites de tests et bibliothèques de tests. Mais bien sûr, un processus d'AQ distinct est nécessaire pour le code de production.
- Avocat en langues: 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'empirer un projet logiciel problématique/en retard. Le problème réside dans la communication et la mise à jour des programmeurs nouvellement ajoutés sur le projet (prend du temps à partir du développement existant), la technologie et parfois le domaine lui-même.
Un programmeur bien pris en charge élimine une grande partie du temps de communication et de la coordination. Disons que vous embauchez un consultant pour Technology X. Au lieu de mettre ce consultant au courant du projet suffisamment pour que cette personne puisse faire tout le codage dans ce domaine, il coache simplement le développeur existant au point où il peut obtenir quelque chose de construit avec une certaine supervision.
L'une des raisons pour lesquelles vous ne voyez pas grand-chose est que la plupart des logiciels sont écrits par une seule personne de toute façon. Les équipes se répartissent le travail et chacun s'en va et fait son truc. La programmation en paire, les critiques et tout ce qui sent la microgestion est mal vu. 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.
En tant que programmeur qui remplissait souvent les rôles de DevOps et Build Master, je sentais que je me retrouvais souvent dans cette position d'être l'équipe chirurgicale ... euh ... mec dans l'équipe. En tant que maître de build, j'avais un aperçu de tout le code et j'étais la première ligne quand il a échoué. Souvent, je le réparais moi-même.
J'étais souvent celui qui écrivait ces systèmes de mesures et mesurait les points chauds dans le code, les parties qui échouaient le plus souvent, qui attiraient le plus de rapports de bogues, etc. Je n'ai pas simplement publié les résultats à l'équipe que j'analyserais eux aussi, trouver le problème qui a causé le problème et a proposé des solutions et des changements architecturaux pour y remédier.
En tant que DevOps, j'automatisais d'énormes pans de processus et de frais généraux. Je rechercherais des technologies et des outils qui faciliteraient la vie de l'équipe, de toute l'équipe, des développeurs aux testeurs QA en passant par les opérations informatiques jusqu'à la gestion. Mon rôle était de comprendre le processus, oui; mais en gardant les yeux fixés sur l'équipe (les humains réels) en utilisant (souffrant à travers) ce processus, j'ai pu le distiller au point de le rendre complètement transparent tout en obtenant une multitude de données utiles pour obtenir une vue objective de cela. "vue d'ensemble" toujours insaisissable.
C'est une position ingrate d'avoir et probablement pourquoi elle est tellement rejetée. 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 prise pour acquise. Mais je savais, en fait j'ai mesuré, l'impact multiplicateur que ce travail peut avoir sur la productivité d'une équipe et ça vaut bien l'investissement.
Alors oui, je pense que ce rôle est toujours très vivant aujourd'hui, même s'il a certes évolué par rapport à ce qu'il était à l'époque.
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 rôles uniques effectués par des spécialistes, plus nous suivons la philosophie de "l'équipe chirurgicale" (bien que peut-être pas exactement de la manière décrite ).
D'après mon expérience, la philosophie de devOps selon laquelle chaque personne devrait être capable de toutes les tâches est un retour au modèle d'abattage de porcs (pour ne pas dire que c'est mauvais, juste différent).