开发人员可以从其他行业中学到很多东西。作为一个思考练习，是否可以使用敏捷技术建造一架客机？
暂时忘记费用;对硬件（机身，机翼等）以及软件使用迭代和增量开发是否可行，并且仍然提供了一种在交付时满足客户要求的工作和安全产品？
重构飞机是否有意义？
答案 0 :(得分：7)
软件中的敏捷和制造中的敏捷实际上是完全不同的，尽管它们具有相似的原则和价值。
20世纪50年代日本出现了制造业的敏捷。阅读W.E.戴明和丰田生产系统了解更多。这一切都是为了不断改进产品的过程。
软件中的敏捷在20世纪90年代初发展成为一种快速发展模式。这一切都是为了不断改进产品。
你当然可以使用敏捷制造方法建造飞机，毫无疑问，有些已经存在。任何在日本建造的东西肯定都会在那里建立敏捷制造（在小学教授）。
您无法使用敏捷软件方法构建飞机，因为您无法承担快速更改产品的费用 - 在软件更改中，错误很便宜且复制是免费的。航空业不是这种情况。
您可以使用敏捷软件方法设计原型平面 - 但必须进行标准化才能进行复制（设计任务本身）。
答案 1 :(得分：6)
您如何使用测试驱动开发？你会在每次迭代时自动构建和测试一架飞机吗？你能够建造十分钟吗？改变飞机有多容易？即使您的设计非常灵活，建筑物也需要将一些组件发送到特殊工厂，因此没有中间反馈。
从设计使用CAD软件，你需要制作一个模具，取出一块光纤，把它放在飞机上。等等。所以这里一个微不足道的变化有一个非常重要的成本。在敏捷中，您可以进行一些非常小的改动，并在20分钟内对其进行测试，构建并准备发货。如果小的变化是昂贵的，那么短的开发周期和重构将不会那么有用。您的反馈可能需要一周以上的时间，所以有充分的理由提前思考瀑布模型。除非您正在编程，否则每次尝试都需要物理材料的成本。 Idea并不新鲜。木匠测量两次。程序员只需先编码再测试。
总结。可能有一些相似之处，但它肯定会是相同的。
答案 2 :(得分：5)
我要说“有点”。事实上现在有一个例子，我认为非常接近回答这个问题。
波音公司现在尝试使用新款787进行此操作 - 请参阅以下内容：Boeing 787 - Specification vs. Collaboration （从777到787，初始规格文件据称从2500页改为20页技术。）来自世界各地的供应商正在独立开发这种飞机的部件。 （我们称之为“团队”。）
所以，我想说是的，但与此同时，创建飞机的迭代导致了2年多的延迟并导致了这样的故事 - （{{3 }}）
飞机是否会建成？是的，当然会的。但是当你看到橡胶在这里上路时，似乎“整合测试”只有一次。
编辑：与此同时，这种技术转变导致建造了一种新型飞机，这种飞机是用全新的材料建造的，可以说是世界上最先进的飞机之一。这可能是更敏捷方法的直接结果。也许这实际上是个问题 - 不是“你能吗？”但是“如果敏捷延迟复杂的系统，它是否会在收益中提供更具创新性的产品？”答案 3 :(得分：3)
丰田开创了精益方法所依赖的精益生产。对于飞机硬件的构建，精益生产将是最佳选择，对于软件而言，敏捷方法将是最佳选择。
为工作选择合适的工具。
关于TPS如何创建和运作的好书 http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176
答案 4 :(得分：2)
我认为在这种情况下你的想法太大了。敏捷就是把事情分解成更多可管理的部分然后反对。 Agile（特别是XP）的整个想法是你首先进行测试，以便减少错误的数量，并且因为平面软件需要具有非常高的代码覆盖率，因此我认为它非常合适。 / p>
你不会'重构'飞机的机制，但如果它们不安全你会调整它们，这就是你的整个迭代方法。
我听说过用敏捷方法论编写的空中交通管制软件推动它向前发展。
答案 5 :(得分：1)
这取自http://requirements.seilevel.com/blog/2008/06/incose-2008-can-you-build-airplane-with.html
***Actually, that’s not true,***
我的第一个猜测 - 这可能与系统和软件工程之间的一些核心差异有关。我将简化这一点，并说它是关于规模的。系统项目只是软件和硬件项目的超集，集成和部署了这些项目的一些组合。部署系统项目的团队非常庞大。此处讨论的许多项目适用于需要规范和可追溯性的政府或受监管系统。我可以看到系统项目的子集实际上是如何使用敏捷（纯软件组件）开发的，但我不相信整个端到端项目可以。将此置于上下文中，假设您正在构建一架飞机 - 一种非常常见的系统工程项目类型。你能看到这个使用敏捷吗？
除了所有的怀疑主义之外，我确实认为迭代开发肯定可以在系统项目中很好地运作，而且大多数人都不会认为这一点。事实上，如果我们能找到灵活处理系统项目的例子，我会很喜欢它，因为我在系统工程会议上的第一感觉是对更轻的流程的渴望。
我决定在会议围墙之外做一些研究，不过，我发现了一篇关于这个确切主题的精彩文章 - 系统与软件联盟的Richard Turner博士的“迈向敏捷系统工程流程” 。这篇文章布置得很好，我强烈建议你阅读它。他定义了敏捷是什么以及他认为大多数系统工程项目不敏捷的问题。例如，他建议高管和项目经理倾向于相信所涉及的团队对我们正在构建的系统有完美的了解，因此我们可以提前计划出来并按照完美的时间表完成执行。
敏捷可以使用复杂系统
他谈到了敏捷概念如何在系统项目中发挥作用。以下是他的文章中总结的几个例子：
基于学习：传统的V模型意味着一次性旅行，意味着一次重新学习。但是，也许可以重新解释模型以允许通过它进行多次迭代来实现此目的。
以客户为中心：通常，系统工程流程不支持在整个项目中与客户进行多次交互（只是预先收集需求）。也就是说，他参考了一项研究，指出系统项目中存在的已知问题。因此，也许应该调整流程以实现这一目标，特别是允许它们帮助确定整个项目的需求优先级。
短迭代：迭代在很大程度上是闻所未闻，因为V模型是一次性通过开发生命周期。也就是说，在许多情况下，通过测试进行原型设计的迭代可以在系统工程中完成。问题在于在每次迭代结束时提供完整的东西。他认为这对于大型部署中的客户来说并不像降低风险，验证要求等那么重要。这是记住飞机示例的一个重点！我们能在2周后连飞机的工作部分吗？即使是在飞机上运行子系统的软件呢？
团队所有权：系统工程是由流程驱动的，所以这个很棘手。特纳博士提出这样的想法：或许允许系统工程师驾驶它而不是驱动它们的过程，而对管理更加不舒服，可能会产生更有效的结果。
答案 6 :(得分：1)
有一个飞机发动机工厂的故事（1999年9月）。他们的方法看起来很敏捷：
答案 7 :(得分：1)
是的，你可以做到。但是，如果您过于密切地遵循敏捷软件开发技术，那么由于活动成本的变化，这将是天文数字的昂贵。
考虑设计和构建的相对成本。如果我们将编码作为软件设计过程的一部分，那么设计绝对是昂贵的部分，并且构建非常简单且便宜。大多数敏捷项目计划至少每次发布几次迭代。因此，我们可以通过持续构建过程进行小规模迭代。两周一次必须组装一架飞机时不那么容易。更糟糕的是，如果你真的计划“释放”它。你可能需要获得适航性和安全性。安全人员也参与敏捷过程。
我真的很想看到它尝试过。
答案 8 :(得分：0)
是的，您可以使用敏捷技术构建复杂系统，但我不知道是否将其用于此特定系统。
飞机的问题是安全问题。这意味着需要采取一切预防措施，从正确识别和解释要求到验证和验证每一行代码。
此外，通过确保编程逻辑合理并正确满足其条件，应该使用正式的方法来确保系统真正安全。
答案 9 :(得分：0)
我很确定答案是无关紧要的。即使你可以，也不会被允许。安全要求太多了。您甚至不会被允许使用敏捷开发飞行软件。例如，您没有Agile中的软件需求规范（SRS）。然而，对于可能影响飞行安全的飞机上的任何航空电子设备软件，您将需要SRS。
答案 10 :(得分：0)
当然可以重构一架飞机。
当一个重构时，一个修改源代码，而不是二进制文件。对于一架飞机，它完全是一样的：一个修改蓝图，而不是平面本身。