Adam Smith vs. Fullstack-Entwickler - und Produktivität in DevOps?

Mit der Arbeitsteilung sind Sie 240-mal effektiver (am Beispiel einer Stiftfabrik, in der Stifte in 18 Schritten hergestellt werden).

Warum sind dann multi-qualifizierte Rollen so gefragt, wenn dies tatsächlich die Produktivität mindert - oder lag Smith einfach falsch, warum dann?

Die Suche nach "Fullstack-Entwicklern" ist bei Google immer noch im Trend, jedoch anscheinend langsamer als vor zwei Jahren:

=====

Zusammenfassend lässt sich sagen , dass ein Full-Stack-Entwickler praktisch die gesamte Wertschöpfungskette abwickeln kann (korrigieren Sie mich, wenn ich mich irre):

• Diskutieren Sie mit Kunden und verfeinern Sie die agilen Anforderungen für seinen Teil des Auftrags
• Entscheiden Sie, welche Architektur, Werkzeuge und Komponenten Sie mitnehmen möchten - geben Sie ihm einfach ein Notizbuch
• Schreiben Sie Code für Frontend, Backend und Integration, der geräteübergreifend kompatibel ist und nicht viele Tests erfordert oder ihn enthält
• Verwenden Sie für Profil- und Scapedaten Cloud AI / ML-APIs für erweiterte Funktionen
• Schreiben Sie den erforderlichen IaC-Code und das Rollout auf
• Seien Sie im Falle von Fehlern oder Verkaufsprozessen auf Abruf
• Achten Sie auf sicherheitsrelevantes Design, allgemeine Patches, Migration und Modernisierung
• Konto Zeitplan in einer überprüften Art und Weise, um die Rechnungsstellung des Arbeitgebers zu erleichtern
• ... habe ich etwas vergessen?

UPD - " Wir brauchen die Produktivität der Spezialisierung, aber wir wollen nicht das einheitliche Weltbild der" extremen Arbeitsteilung ". (DevOps Guys, " DevOps, Adam Smith und die Legende des Generalisten " , 2013-2016)

Es gibt zwei Arten von Arbeiten:

1. Ausbeutung - Gut definierte Arbeit, die leicht in gut definierte Phasen unterteilt werden kann, wobei jede Phase für sich erlernt und gemeistert werden kann und die Übergabe zwischen den Phasen keine Kommunikation erfordert.

2. Exploration - Undefinierte Arbeit, die Lernen und Experimentieren erfordert, um jede Phase und Übergabe zwischen den Phasen zu erreichen, erfordert eine enorme Menge an Kommunikation über alles Lernen und den Status des Projekts.

Adam Smith befasst sich ausschließlich mit Ausbeutung und überhaupt nicht mit Erforschung. Die in den Forschungs- und Entwicklungsabteilungen der Branche geleistete Arbeit ist per definitionem hauptsächlich Exploration und wird daher von Adam Smith in keiner Weise behandelt.

Wir haben jedoch gesehen, dass die Anwendung von CI / CD in späteren Phasen der kontinuierlichen Verbesserung, bei denen es sich teilweise um ausbeuterische Arbeiten handelt, zu ähnlichen Produktivitätssteigerungen führen kann, die in gewisser Weise wahrscheinlich auf Adam Smith zurückzuführen sind.

Adam Smith musste sich nicht mit der Weitergabe von Informationen von einer Stufe zur nächsten befassen. Dies ist ein kritischer Bestandteil jedes bedeutenden IT-Projekts. Ein Fullstack-Entwickler hat also die wesentlichen Vorteile, dass:

• Sie müssen mit niemandem in einer anderen Abteilung sprechen, um die Dinge zu erledigen
• Sie müssen nicht darauf warten, dass die anderen Leute dazu kommen
• Es gibt viel weniger Chancen, dass etwas bei der Übersetzung zwischen verschiedenen Ebenen verloren geht

Weitere Informationen zur Bedeutung des Informationsaustauschs in IT-Projekten finden Sie in Fred Brooks Mythical Man Month .

Meiner Meinung nach hat die Antwort viel mit dem Umfang und der Verfügbarkeit von Ressourcen zu tun.

Ich glaube, dass die Theorie von Adam Smith nur in großem Maßstab angewendet werden kann - ganze Nationen / Volkswirtschaften im ursprünglichen Kontext oder - im SW-Entwicklungskontext - große Entwicklungsteams.

In einem großen Team ist es in der Tat effizienter, spezialisiertere Humanressourcen einzustellen:

• Sie sind keine Rockstars - in so großen Organisationen oft als Gefahrenzeichen angesehen
• Sie sind in der Regel einfacher zu finden und billiger als diejenigen mit einem breiteren Kompetenzspektrum
• Sie erhöhen normalerweise nicht das Abnutzungsrisiko - zum Beispiel werden sie nicht unglücklich sein, weil sie nur einen Teil ihrer Fähigkeiten einsetzen.
• In einem (vielleicht seltsamen) Devopsie-Vergleich kann das Prinzip "Vieh gegen Haustiere" in solch größeren Organisationen angewendet werden, und zwar aus ganz ähnlichen Gründen. Diese spezialisierten Ressourcen sind aus betriebswirtschaftlicher Sicht buchstäblich nur die Kopfressourcen in Personalpools, deren Größe bei Bedarf schnell angepasst werden kann, typischerweise durch Einstellung / Entlassung.

Oh, und solche Teams können nur dann funktionsfähig sein, wenn sie durch hochwertige Architektenressourcen ergänzt werden, die erforderlich wären, um das Produkt in kleinere, spezialisierte Aufgaben aufzuteilen, die mit den spezialisierten Ressourcen gelöst werden können.

In kleineren oder sogar Ein-Mann-Teams (normalerweise Start-ups oder sogar isolierte kleinere Teams in größeren Organisationen) ist es ineffektiv oder sogar unmöglich, solche Ressourcen zu nutzen und dennoch die Arbeit zu erledigen:

• Sie haben einfach nicht das Budget / die Ressourcen, um die vielen verschiedenen spezialisierten Ressourcen einzustellen, die für die gesamte Produktentwicklung erforderlich sind
• Sie suchen / schätzen Rockstars, die mehrere Hüte tragen und sofort mit großer Flexibilität die Rolle wechseln können, ohne Verzögerungen und zusätzliche Personalkosten zu verursachen

Ich betrachte mich als Fullstack-Entwickler auf der Grundlage der folgenden Verantwortungskombination:

Frontend- und Backend-Programmierung

Ich kann bis zu einem gewissen Grad Änderungen an der Benutzeroberfläche vornehmen: HTML schreiben, CSS (als Webentwickler) und in einem gewissen Umfang Daten aus der Datenbank an die Benutzeroberfläche liefern, diese in einem Dienst bereitstellen usw.

Ich lasse das Testen, die Architektur und die anderen Dinge außer Acht. Treffen von Kunden kann der Arbeitsbeschreibung hinzugefügt werden.

Gegenteil

Meiner Meinung nach wäre das Gegenteil eine strikte Rolle der UI-Leute und der Back-End-Leute.

Schlussfolgerungen

Ich sehe Full Stack nicht wirklich so voll, wie Sie es erwähnt haben, eher wie ein ausgefallener Ausdruck wie Agile oder Cloud, der unter bestimmten Umständen nur erwähnt werden muss, um die Aufmerksamkeit der Leute zu erregen, und die tatsächliche Implementierung kann sehr unterschiedlich sein. Zumindest in Bezug auf Scrum und Agile habe ich so viele Variationen gesehen, dass die Begriffe keine Bedeutung mehr haben.

Kurz gesagt, ich glaube nicht, dass Adam Smith sich geirrt hat, aber ich glaube, dass es einige gravierende Unterschiede zwischen seinem Modell der Arbeitsteilung in der Fertigung und den Silos in der Softwareentwicklung gibt.

Erstens war das Pin-Factory-Beispiel (soweit ich weiß) lediglich hypothetisch; Obwohl die meisten modernen Fertigungsbetriebe ihre Wurzeln auf diese Arbeitsteilung zurückführen können, sind mir keine Studien bekannt, die diese Hypothese tatsächlich wissenschaftlich überprüft haben.

Zweitens befasste sich Smith hauptsächlich mit der Herstellung von materiellen Gütern; Es gibt bestimmte materielle Ergebnisse im Zusammenhang mit der Materialherstellung, für die es in der Softwareentwicklung keine ähnlichen Analoga gibt. Beispielsweise sind bei der Herstellung von Stiften physikalische Abmessungen als funktionale Anforderung wichtig; Es gibt keinen offensichtlichen Vergleich zu Software. Dies ist wichtig, da greifbare Objekte durch exakte Wiederholung repliziert werden können. Softwareentwicklung ist nie das gleiche Problem zweimal. Entwickler entwickeln gängige Methoden, um vorhersehbare Ergebnisse zu erzielen. Sie können jedoch niemals dasselbe Problem zweimal programmieren. Jede im Stapel entwickelte Komponente weist im Gegensatz zu physischen Komponenten Komplikationen auf, und diese Komplikationen haben Interaktionen, die nicht greifbar sind (Größe, Gewicht, Länge usw.). Einem Stiftzeiger ist es egal, wie der Drahtschneider funktioniert. solange der draht nach spezifikation abgeschnitten wird In der Softwareentwicklungdie grenzen sind nie ganz so klar .

Von Full-Stack-Entwicklern wird nicht erwartet, dass sie die gesamte Arbeit selbst erledigen (sie sind nicht als Single-Pin-Hersteller gedacht), von ihnen wird jedoch erwartet, dass sie in der Lage sind, alle Elemente des Stacks und deren Interaktion zu verstehen. Ein Full-Stack-Team sollte aus T-förmigen Personen bestehen, die sich auf einen oder mehrere Bereiche spezialisiert haben, aber das Spektrum verstehen (und in der Lage sein können, auf einer bestimmten Ebene einzugreifen).

Ich denke, dass Smiths Arbeit in der Softwareentwicklung im Bereich des Kontextwechsels (oder Multitasking ) gilt. Wenn ein einzelner Entwickler für alle Bereiche der Entwicklung verantwortlich ist, braucht es Zeit, um von Verantwortung zu Verantwortung zu wechseln. Auf der Skala kann die Zusammenarbeit zwischen Teammitgliedern mit unterschiedlichen Erfahrungen im selben Produktteam das Gleichgewicht zwischen Kontextwechsel und komplexen Interaktionen herstellen.

Ein wichtiger Punkt zu verstehen ist, dass Arbeitsteilung nicht immer eine andere Person pro Schritt bedeutet.

Ich nahm meine eigene Geschichte in einer Autofabrik auf, ich befand mich an einer Sitzmontagekette, um einen vollen Sitz mit Airbag, Leder, Kopfstütze usw. zu bekommen. Die Kette war in 9 Stufen unterteilt. Wir haben 9 an der Kette gearbeitet. Jede Person absolvierte jeweils nur eine Stufe, aber jede Stunde wechselten wir zur nächsten Stufe, um zu viele Wiederholungen zu vermeiden. Der Arbeitstag dauerte 8 Stunden, so dass wir nicht jeden Tag auf die Bühne kamen.

Dies ist genau eine Arbeitsteilung, bei der Sie zu einem bestimmten Zeitpunkt nur einen Schritt der Montage ausführen, was Sie nicht daran hindert, die gesamte Montage durchführen zu können.

Wie bereits in anderen Antworten erwähnt, ist dies ein wenig anders als bei der Softwareentwicklung, aber ich denke, dies gibt Aufschluss darüber, warum ein Full-Stack-Entwickler sich bei der Arbeitsteilung nicht ausschließt, jemand mit den Fähigkeiten, den gesamten Lebenszyklus einer Anwendung zu bewältigen, nicht erforderlich, um es die ganze Zeit zu tun.

Wenn ich FullStack-Entwickler höre, denke ich im Allgemeinen eher an jemanden, der in der Lage ist, effiziente Back-Ends und eine nette Benutzeroberfläche gleichzeitig zu programmieren, im Gegensatz zu Front- und Back-Dev.