制造与软件开发[关闭]

人们常说，与制造业相比，软件产业还不成熟。特别是关于过程驱动。

问题：作为开发人员，我们可以从制造过程中学习吗？采用他们的流程是否可以提高软件开发的成功率？

我的观点：在制造产品时，产品的生产很大程度上是过程驱动的。您可能有一家工厂，每个人都有他们要遵循的一组特定任务。工人（或机器人）可能整天拧紧螺丝。然后，下一位专家将执行该过程中的下一个任务。工人（和机器人）不会阻止过程，也不会“动态”地弥补问题。零件在整个过程中都经过搅动，输出是成品。它运作良好，公司获得了99.99966％的无缺陷产品。随着时间的流逝，公司消除了效率低下的问题。这令人印象深刻，并且很可能是行业成熟的标志。

在制造过程中，定义的过程可以从字面上创建最终产品。我认为在软件中不是这种情况。我们可能有用于源代码控制，代码审查，检入表，需求收集，SDLC等的流程。但是执行这些流程并不能本身创建成品。这些过程可能是有益的，但与实际创建正交。

假设您的公司与软件开发公司签有合同，该软件将搜索数百万张图像以查找罪犯的面孔。尽管有繁重的过程驱动环境，开发人员仍必须“即时”创建事物。动态地做事违背了制造业的精神。机器人无需考虑即可执行良好的制造过程。

为了创建尚未在人的脑海中扎根的复杂算法，必须实时创建事物。软件开发不是过程的后续，而是计算机要执行的过程的创建。那是根本的区别。无论我们围绕开发进行了多少正交处理，我们在创建时总是会“动态”进行。

与我交谈的每个人似乎都同意制造业的观念。我一个人在想吗？

软件开发与制造之间的根本区别在于，对于软件而言，设计阶段实际上是整个过程。实际生产（传统制造中的装配线零件）只需复制几个文件即可。在软件中，产品设计就是产品。

因此，是的，我们可以从制造过程中学习，但前提是要记住，我们必须关注设计阶段，而不是生产阶段，并且必须建立许多制造过程来应对昂贵的生产链的特定限制，这根本不适用于软件。

流程模型的一个示例在软件中运行良好，但在产品设计中却经常失败，它是迭代设计-从最小的原型开始，并在每次迭代中添加功能。制造原型车来查看新的后窗把手设计看起来是很荒谬的，但是在软件中，这是有道理的（只需按F5键并等待几秒钟-瞧，准备试驾）。

如果我们确实关注产品设计过程，那么最好的行业可以分为两类：

• 那些可以商品价格实现生产的国家；例如唱片业（CD的价格的1％或以下是烘烤和印刷），图形媒体等。
• 数量如此之少以至于设计阶段是最主要的成本因素的产品（豪华商品，高度定制的产品，利基市场...）

尝试并应用从物理制造到软件开发的流程是一个基本错误：软件开发不是重复性的（如果在您的工作中，请去找另一份工作），它只是部分可预测的，物理上的局限性很小（硬件速度为一），并且所采用的方法和结果都可能非常个人化。将流水线哲学应用于本质上是分析和创造性思维的问题上，可能（而且经常如此）产生毁灭性影响。

如果您想一遍又一遍地编写相同的软件（而不是简单地复制它），则可以通过装配线非常有效地做到这一点。

但是软件创建不是重复性的任务，每个模块都是唯一的。这就是为什么与制造业的比较是无效的。

我认为您要寻找的答案在这里适用或切合实际。我想您想知道的是，我们如何将我们的流程设置得更像制造业。取而代之的是，我认为真正的问题是“知道制造业和其他行业如何制造优质产品，我们可以学到什么？” 或“软件行业可以做什么来提高质量？”

不幸的是，由于软件行业本身仍然不知道答案，因此答案尚不清楚。为了能够回答这个问题，软件行业需要研究什么有效，为什么有效？例如，已有研究表明，测试驱动设计（TDD）可以提高质量。尽管生产力问题似乎仍未得到解答，或者至少尚未完全理解。到目前为止，证据显示：

• 代码审查非常出色，可以发现最多的错误，但是审查的有效性在审查的第一个小时后就急剧下降。鉴于普通人每小时只能阅读几百行代码，因此建议开发人员应将更改分解为较小的部分。
• 发现错误所需的时间越长，修复该错误的费用（时间和金钱）就越多。因此，如果开发人员在编写代码时发现它，我们说成本为1。如果单元测试以后发现它，成本为10，如果EVT发现它为成本100，依此类推。
• 有证据表明，要求越复杂，解决方案就越复杂，而解决方案越复杂，就越有可能出现错误。

几年前，有一个名叫格雷格·威尔逊（Greg Wilson）的人就此作了精彩的演讲。这是演讲的链接：格雷格·威尔逊演讲

除此之外，我想说的是回顾自己的工作，找到带有引入的错误类型以及遇到哪些困难的主题。编译这些结果，然后创建一个清单以插入到不同位置的流程中，以帮助您做得更好。我个人回顾了过去几年的工作，发现我介绍的问题有一些共同的主题。我特别发现

• 我不经常记得构建所有导致我破坏构建的变体。
• 很多时候，我不会为每次更改考虑以下内容。好的情况，坏的情况和例外情况。
• 可能发生的所有可能情况。请注意，这确实很难，因为其中有很多。

由于发现了错误的某些主题，因此我创建了自动使用的清单，这是由于将其插入到脚本中可以帮助我解决这些问题。有一本名为“清单清单”的书，详细介绍了如何善加利用它们。我个人非常有见地。

这与采用“他们的”流程无关。这是关于采用“某些”过程的过程，这些过程没有使用装配线过程进行创造性工作的通常且广为人知的危害。这里要注意的最重要的事情是过程质量直接转换为产品质量的想法。

最好的过程或产品就是适合预定使用场景的过程，例如戴着手套。要考虑的是，实际的代码编写部分至少是宏观一级的，而不是重复的。所有其他方面（例如版本控制，错误跟踪，计划，估计，度量等）都是有效的，并且使用标准，量身定制且经过验证的过程至少可以在这些方面帮助您。

因此，不能，软件开发过程不能比作流水线生产，因此“他们的过程”并不可行，但是制造业中产品的生产设计/产品设计阶段可以作为灵感来源。

问题：作为开发人员，我们可以从制造业的过程中学习吗？采用他们的流程是否可以提高软件开发的成功率？

答：当然可以。尽管软件开发是一个创造性的过程，但软件开发人员可以从制造中汲取很多教训。软件开发本身就是一个过程，它包括许多其他过程。您定义和控制这些流程的能力越强，就可以更好地控制整个软件开发的流程。这并不意味着您应该规定开发人员进行的每一次按键操作；这仅意味着作为开发人员，您自然会以特定顺序执行任务，并且这些任务通常可以得到管理。这里有些例子：

• 缺陷跟踪：发现或报告错误时，会发生什么情况？您是否将其写下来并粘贴在“调查”峰值上？您以后是否一次一次清除这些碎片，进行调查，最后将其移至“已解决”的峰值？如果您每次收到错误报告时都能做到这一点，那么您将拥有一个定义明确，可衡量的流程，并且比拥有花哨的高科技缺陷跟踪系统的人要好得多一些团队成员以其他方式或根本不跟踪错误。

• 版本控制：您很有可能在工作场所使用版本控制，并且当每个人都以相同方式使用版本控制时，版本控制显然要有用得多。

• 产品设计：您是否决定通过将飞镖扔到贴满便笺的墙上来实现哪些功能？如果是这样，您就有一个过程。我认为没有人会认为这是一个伟大的过程，但至少这是一个起点。如果您更改流程，那么如何确定更改实际上是一项改进，除非您前后进行了测量？你不能

• 代码审查：如果每次审查的审查过程和编码标准都发生了变化，那么代码审查会有用吗？当然不是。

• 软件开发生命周期：整个分析->设计->实现->测试->维护周期是一个应该明确定义的过程。

在每种情况下，都有一个适当的过程可以使您测量输入和输出，并确定所做的更改是否具有预期的效果。没有适当的流程意味着您只是在猜测何时尝试改善工作方式。这实际上就是制造业的全部内容，只有在适当时借用连续的制造业优化工具才有意义。

整个领域致力于定义和改进用于创建和维护软件的流程。这就是所谓的软件工程。在阅读有关CMMI时，您对开发过程有疑问也就不足为奇了-CMMI是软件工程学院的产品。

软件开发已经采用了许多制造概念：

• 很难不看到Eli Whitney的可互换零件对OOP和基于组件的开发的影响。

• 在软件开发中使用的项目管理技术与为制造业开发的项目管理技术并没有太大区别。仅举两个例子，软件界最近才采用了几十年前在丰田公司开发的看板概念，而甘特图早在制造第一台电子计算机之前就已用于制造业。

• 为制造而开发的质量管理方法（如六西格玛）已适应于软件开发。

尽管有繁重的过程驱动环境，开发人员仍必须“即时”创建事物。

您是在告诉我，有人要自己决定是否将补丁添加到面部识别程序包中，然后他们将其添加到生产版本中，而无需先在跟踪系统中创建问题，并且要对设计进行审核，将代码检查到版本控制中，还是让测试人员首先查看它？我们的流程出于某些很好的理由而需要这些东西。如果“即时”表示“过程之外”，那是不可接受的。

动态地做事违背了制造业的精神。

同样，如果“即时”表示“过程之外”，那您是对的。但是，如果您认为制造业不需要快速思考和开发解决问题的创造性解决方案，那您就错了。生产过程中会遇到各种各样的问题-纸杯蛋糕的奶油填充不足，涂漆的表面突然停止通过QA的划痕测试，20％的制成品缺少重要的固定环，面团搅拌系统损坏了关键部分