Adam Smith与全栈开发人员-DevOps的生产力？

通过亚当·斯密（Adam Smith），分工可以使您的效率提高240倍（例如以18步生产销的销工厂为例）。

如果这实际上降低了生产率，那么为什么会需要多技能的角色？或者史密斯只是错了，那又为什么呢？

在Google上搜索“全栈开发人员”的趋势仍然很高，但显然比两年前要慢：

=====

综上所述，全栈开发人员几乎可以完成所有价值链（如果我做错了，请纠正我）：

• 与客户讨论并完善其工作中可行的敏捷性要求
• 确定选择哪种架构，工具和组件-只给他一个笔记本
• 为前端，后端和集成编写代码，这些代码跨设备兼容并且不需要大量测试，也不需要包含它
• 剖析和浏览数据，使用Cloud AI / ML API获得高级功能
• 编写所需的IaC代码并推出
• 在出现错误或销售流程时随时待命
• 注意与安全相关的设计，整体修补，迁移和现代化
• 以详细的方式查看帐户时间表，以简化雇主的发票
• ...我忘记了什么吗？

UPD-“ 我们需要专业化的生产力，但我们不希望看到“极端劳动分工 ” 的孤立世界观。（DevOps Guys，“ DevOps，Adam Smith和通才的传奇”，2013-2016年）

有两种类型的工作：

1. 开发 -定义明确的工作可以轻松地划分为定义明确的阶段，每个阶段都可以自己学习和掌握，并且阶段之间的切换不需要沟通。

2. 探索 -不确定的工作，需要学习和试验以完成每个阶段，并且阶段之间的切换需要大量交流所有学习和项目状态的信息。

亚当·斯密（Adam Smith）完全将自己与剥削有关，而不与勘探完全挂钩。按照其定义，该行业研究与开发部门所做的工作大部分是探索性的，因此Adam Smith不会对其进行任何介绍。

但是我们已经看到，在后来的持续改进阶段（部分是开拓性的工作），CI / CD的应用可以带来类似的生产率提高，这在某种程度上可以由富有想象力的人追溯到亚当·斯密。

亚当·斯密（Adam Smith）无需考虑将信息从一个阶段传递到另一个阶段。这是任何重要的IT项目的关键部分。因此，全栈开发人员具有以下显着优势：

• 他们不必与另一个部门的任何人交谈就可以完成工作
• 他们不必等待其他人适应它
• 一层和另一层之间的翻译中丢失某些东西的机会要少得多

有关信息传递在IT项目中的重要性的更多信息，请参阅Fred Brook的Mythical Man Month。

恕我直言，答案与规模和资源可用性息息相关。

我相信亚当·史密斯（Adam Smith）的理论只能大规模地使用-原始环境中的整个国家/经济体，或者在西南软件开发环境中-大型开发团队。

实际上，在一个大型团队中，雇用更多专门的人力资源会更有效：

• 他们不是摇滚明星-在如此大型的组织中通常被视为危险信号
• 与拥有广泛专业知识的人相比，他们通常更容易找到，更便宜
• 他们通常不会增加减员的风险-例如，他们不会感到不满，因为他们仅使用部分技能。
• 在（也许很奇怪的）迷惑的比较中，“牛与宠物”的原则可以应用在这样的大型组织中，原因也很相似。从业务的角度来看，这些专业资源实际上只是人力资源库中的人均资源，其规模可以根据需要快速调整，通常可以通过雇用/解雇来实现。

哦，这样的团队只有在拥有高质量架构师资源的补充下才能发挥作用，这对于将产品划分为较小的，专门的任务是必要的，而这些任务可以通过专门的资源来解决。

在规模较小甚至是一个人的团队（通常是初创公司，或者甚至是大型组织中孤立的较小团队）中，使用这样的资源仍然无法完成工作：

• 他们根本没有预算/资源来雇用许多不同的专业资源来覆盖整个产品开发
• 他们实际上在寻找/欣赏可以戴多顶帽子并立即灵活地担任角色的摇滚明星，而又不会造成延误和额外的人力资源成本

基于以下职责组合，我将自己视为全职开发人员：

前端和后端编程

我可以做UI更改，直到某种程度：编写html，css（作为Web开发人员），另一方面，可以扩展到从数据库向UI提供数据，在服务中提供等。

我将测试，体系结构和那些放在一边，与客户见面可能会添加到工作描述中。

相反

在我看来，相反的是UI角色和后端角色的严格角色。

结论

我看不到像您提到的那样，全栈真的真的满了，更像是敏捷或云之类的奇特表达，在某些情况下仅需提起它们来吸引人们的注意力，实际的实现可能会千差万别。至少关于scrum和敏捷，我已经看到了太多的变体，以至于这些术语已经失去了意义。

简而言之，我不认为亚当·史密斯（Adam Smith）是错的，但我确实认为他的制造业分工模型与软件开发的竖井模型之间存在一些严重差异。

首先，据我所知，引脚工厂的示例只是假设的；尽管大多数现代制造工厂都可以将其根源追溯到这种分工，但是我不知道有任何科学地对该假设进行过科学检验的研究。

其次，史密斯主要关注制造物质产品。与材料生产相关的某些有形输出在软件开发中没有类似的输出。例如，在引脚制造中，物理尺寸作为功能要求很重要；与软件中没有明显的比较。这很重要，因为可以通过精确的重复来复制有形的对象。软件开发从来不会两次遇到相同的问题。开发人员开发了通用的方法来产生可预测的结果，但是您永远不会两次编写相同的问题。堆栈中开发的任何组件都具有不同于物理组件的复杂性，并且这些复杂性之间的相互作用超出了实际的度量范围（高度，重量，长度等）。别针指针不在乎剪线钳的工作原理，只要电线根据规格被切断。在软件开发中界限从未如此清晰。

不应由全栈开发人员自己完成所有工作（他们不打算成为一个单一的引脚制造商），但希望他们能够理解栈的所有元素以及这些元素如何交互。一个完整的团队应该由T型人员组成，他们擅长一个或多个领域，但了解范围（并且可以在某个级别介入）。

我认为Smith的工作在软件开发中的正确之处在于上下文切换（或多任务）领域。如果单个开发人员负责所有开发领域，则从责任转移到责任需要时间。大规模地，在同一产品团队中具有不同经验的团队成员之间的协作可以平衡上下文切换和复杂的交互。

需要理解的重要一点是，分工并不总是意味着每个步骤都有不同的人。

我会在一家汽车制造厂里经历自己的历史，当时我在一个座椅装配链上，要得到一个装有安全气囊，皮革，头枕等的完整座椅。该链分为9个阶段。我们9岁时在连锁店工作。每个人一次只能做一个阶段，但每个小时我们都要转移到下一个阶段，以免重复过多。工作日长达8小时，因此我们没有每天上每一节课。

这恰好是一个分工，您在给定的时间仅执行组装的一个步骤，这并不妨碍您能够进行完整的组装。

如其他答案中所述，这与软件开发有点不同，但是我认为这可以说明为什么全栈开发人员不会与分工互斥，而能够处理应用程序整个生命周期的人却并非如此需要一直这样做。

一般来说，当我听到FullStack开发人员的时候，我想到的是更多能够与Front Dev和Back Dev对抗的人，他们可以同时编写高效的后端和漂亮的UI。