Adam Smith vs développeurs fullstack - et productivité dans DevOps?

Par Adam Smith, la division du travail peut vous rendre 240 fois plus efficace (sur l'exemple d'une usine de broches produisant des broches en 18 étapes).

Pourquoi les rôles polyvalents sont-ils si demandés si cela réduit réellement la productivité - ou si Smith avait tout simplement tort, pourquoi alors?

Les recherches de "développeur fullstack" sont toujours sur Google, mais apparemment plus lentes qu'il y a deux ans:

=====

Pour résumer, un développeur de pile complète serait capable de faire pratiquement toute la chaîne de valeur (corrigez-moi si je me trompe):

• Discutez avec les clients et affinez les exigences agiles réalisables pour sa partie du travail
• Décidez de l'architecture, de l'outillage et des composants à prendre - donnez-lui simplement un ordinateur portable
• Écrire du code pour frontend, backend, ingration, qui est compatible avec tous les appareils et ne nécessite pas beaucoup de tests, ou l'inclut
• Profil et données de scape, utilisez les API Cloud AI / ML pour des fonctionnalités avancées
• Rédiger le code IaC et le déploiement requis
• Être sur appel en cas d'erreur ou de processus de vente
• Soyez conscient de la conception pertinente de la sécurité, des correctifs globaux, de la migration et de la modernisation
• Calendrier du compte d'une manière scrupuleuse pour faciliter la facturation de l'employeur
• ... ai-je oublié quelque chose?

UPD - " nous avons besoin de la productivité de la spécialisation mais nous ne voulons pas de la vision insulaire du monde de la" division extrême du travail ". (DevOps Guys, " DevOps, Adam Smith et la légende du généraliste " , 2013-2016)

Il existe deux types de travaux:

1. Exploitation - Un travail bien défini qui peut être facilement divisé en étapes bien définies, où chaque étape peut être apprise et maîtrisée seule et le transfert entre les étapes ne nécessite pas de communication.

2. Exploration - Un travail indéfini, qui nécessite un apprentissage et une expérimentation pour accomplir chaque étape et un transfert entre les étapes nécessite des quantités massives de communication de tous les apprentissages et du statut du projet.

Adam Smith se préoccupe entièrement de l'exploitation et pas du tout de l'exploration. Le travail effectué dans les départements de recherche et développement de l'industrie est par définition principalement de l'exploration et n'est donc en aucune façon couvert par Adam Smith.

Mais nous avons vu que dans les étapes ultérieures d'amélioration continue, qui sont en partie des travaux d'exploitation, l'application de CI / CD peut apporter des gains de productivité similaires, qui pourraient en quelque sorte être attribués à Adam Smith par quelqu'un de très imaginatif.

Adam Smith n'avait pas besoin de considérer la transmission d'informations d'une étape à l'autre. Il s'agit d'un élément essentiel de tout projet informatique important. Un développeur fullstack a donc les avantages importants suivants:

• ils ne doivent parler à personne dans un autre département pour faire avancer les choses
• ils n'ont pas à attendre que ces autres personnes s'y mettent
• il y a beaucoup moins de chances que quelque chose se perde dans la traduction entre une couche et une autre

Pour en savoir plus sur l'importance de la transmission d'informations dans les projets informatiques, consultez le Mois de l'homme mythique de Fred Brook .

À mon humble avis, la réponse a beaucoup à voir avec l'échelle et la disponibilité des ressources.

Je crois que la théorie d'Adam Smith ne peut être appliquée qu'à grande échelle - des nations / économies entières dans le contexte d'origine, ou, dans le contexte du développement SW - de grandes équipes de développement.

Dans une grande équipe, il est en effet plus efficace d'embaucher des ressources humaines plus spécialisées:

• ils ne sont pas des rockstars - souvent considérés comme un signe de danger dans de si grandes organisations
• ils sont généralement plus faciles à trouver, moins chers que ceux ayant un spectre d'expertise plus large
• ils n'augmentent généralement pas les risques d'attrition - par exemple, ils ne seront pas mécontents car ils n'utilisent qu'un sous-ensemble de leurs compétences.
• dans une comparaison de dévopsie (peut-être étrange), le principe "bétail vs animaux de compagnie" peut être appliqué dans des organisations aussi grandes, et pour des raisons assez similaires. Du point de vue des entreprises, ces ressources spécialisées ne représentent littéralement que des personnes dans des pools de ressources humaines, dont la taille peut être rapidement ajustée au besoin, généralement par embauche / licenciement.

Oh, et de telles équipes ne peuvent être fonctionnelles que si elles sont complétées par des ressources d'architecte de haute qualité qui seraient nécessaires pour diviser le produit en tâches plus petites et spécialisées qui peuvent être traitées avec les ressources spécialisées.

Dans des équipes à plus petite échelle ou même un seul homme (généralement des startups ou même des équipes plus petites isolées dans des organisations plus grandes), il est inefficace, voire impossible, d'utiliser ces ressources et de faire le travail:

• ils n'ont tout simplement pas le budget / les ressources nécessaires pour embaucher les nombreuses ressources spécialisées différentes nécessaires pour couvrir l'ensemble du développement du produit
• ils recherchent / apprécient réellement les rockstars qui peuvent porter plusieurs chapeaux et changer de rôle immédiatement avec une grande flexibilité, sans encourir de retards et de coûts RH supplémentaires

Je me considère comme un développeur fullstack sur la base de la combinaison de responsabilités suivante:

Programmation front-end et back-end

Je peux apporter des modifications à l'interface utilisateur jusqu'à un certain point: écrire du HTML, CSS (en tant que développeur Web) et d'autre part dans une certaine mesure fournir des données à l'interface utilisateur à partir de la base de données, les fournir dans un service, etc.

Je laisse les tests, l'architecture et ceux de côté, les clients rencontrés peuvent être ajoutés à la description de travail.

Contraire

Le contraire de mon point de vue serait des rôles stricts des gars de l'interface utilisateur et des gars du back-end.

Conclusions

Je ne vois pas la pile complète vraiment aussi pleine que vous l'avez mentionné, plus comme une expression fantaisiste comme agile ou cloud qui, dans certaines conditions, doit simplement être mentionnée pour attirer l'attention des gens et la mise en œuvre réelle peut varier considérablement. Au moins à propos de Scrum et Agile, j'ai vu tellement de variations que les termes n'ont plus de sens.

En bref, je ne pense pas qu'Adam Smith avait tort, mais je pense qu'il y a de sérieuses différences entre son modèle de division du travail dans la fabrication et les silos dans le développement de logiciels.

Premièrement, l'exemple de l'usine de broches (pour autant que je sache) était simplement hypothétique; Bien que la plupart des usines de fabrication modernes puissent trouver leurs racines dans cette division du travail, je ne connais aucune étude qui ait effectivement testé scientifiquement cette hypothèse.

Deuxièmement, Smith s'intéressait principalement à la fabrication de biens matériels; il existe certaines sorties tangibles associées à la production de matériaux qui n'ont pas d'analogues similaires dans le développement de logiciels. Par exemple, dans la fabrication de broches, les dimensions physiques sont importantes en tant qu'exigence fonctionnelle; il n'y a pas de comparaison évidente avec cela dans le logiciel. Ceci est important car les objets tangibles peuvent être reproduits par répétition exacte; le développement de logiciels n'est jamais le même problème deux fois. Les développeurs développent des méthodes courantes pour produire des résultats prévisibles, mais vous ne codez jamais deux fois le même problème. Tout composant développé dans la pile a des subtilités contrairement aux composants physiques, et ces subtilités ont des interactions au-delà de la mesure tangible (hauteur, poids, longueur, etc.). Un pointeur à épingle ne se soucie pas du fonctionnement du coupe-fil, tant que le fil est coupé selon les spécifications. En développement logiciel,les limites ne sont jamais aussi claires .

Les développeurs de la pile complète ne sont pas censés faire tout le travail eux-mêmes (ils ne sont pas destinés à être un seul fabricant de broches), mais ils devraient être capables de comprendre tous les éléments de la pile et comment ces éléments interagissent. Une équipe de pile complète devrait être composée de personnes en forme de T qui se spécialisent dans un ou plusieurs domaines, mais comprennent le spectre (et peuvent être en mesure d'intervenir à un certain niveau).

Là où je pense que le travail de Smith est vrai dans le développement de logiciels, c'est dans le domaine du changement de contexte (ou du multitâche ); si un seul développeur est responsable de tous les domaines du développement, il faut du temps pour passer d'une responsabilité à l'autre. À grande échelle, la collaboration entre des membres de l'équipe ayant des expériences différentes au sein d'une même équipe produit peut équilibrer le changement de contexte et les interactions complexes.

Un point important à comprendre est que la division du travail ne signifie pas toujours une personne différente par étape.

Je prendrais ma propre histoire dans une usine automobile, j'étais sur une chaîne d'assemblage de siège, pour obtenir un siège complet avec airbag, cuir, appuie-tête, etc., la chaîne était divisée en 9 étapes. Nous travaillions sur la chaîne. Chaque personne ne faisait qu'une seule étape à la fois, mais toutes les heures, nous passions à l'étape suivante pour éviter trop de répétitions. La journée de travail était de 8h donc nous n'avons pas pu monter sur chaque scène tous les jours.

Il s'agit exactement d'une division du travail où vous ne faites qu'une seule étape de l'assemblage à un moment donné, cela ne vous empêche pas de pouvoir faire l'assemblage complet.

Comme déjà indiqué dans d'autres réponses, c'est un peu différent du développement de logiciels, mais je pense que cela explique pourquoi un développeur Full Stack n'est pas mutuellement exclusif avec la division du travail, une personne ayant les capacités de gérer tout le cycle de vie d'une application n'est pas nécessaire de le faire tout le temps.

De manière générale, lorsque j'entends le développeur FullStack, je pense plus à quelqu'un capable de coder des back-ends efficaces et une interface utilisateur agréable en même temps, en opposition avec Front et Back Dev.