我曾是一名国防部承包商（是编写代码的那种，不是开枪的那种），差不多有15年时间，这是一段…

我没有读过那份文件，但我曾处理过诉讼案（我是一名律师），这些案件的核心主张是敏捷软件开发不如瀑布模型安全或无bug。基本上在医疗设备（或相关）领域，提出的观点是“快速失败”是非法的，缺乏足够的安全检查。敏捷软件开发对非工程师来说很难接受。律师和业务人员无法理解逐步构建实际上可以减少错误并提高质量的概念——因为他们工作的模式是通过流程计划文档和检查清单。

出于好奇，像软件开发这样具有高需求、高可转移技能的人，为什么会在一个他们通常不喜欢的地方工作15年而没有更早离开？

> 问题在于，你不能把一个流程交给软件机器人，然后交付任何复杂度的软件。这与很多（但不是全部）国防部的范式相违背，看到他们可能正在改变，这很有趣。 我（外部）的印象随着多年来听到的内容而改变，以至于我现在认为国防部和军队非常清楚无人机并不是真正可以互换的，他们在每个层级上都会培养那些“能完成任务”的人，并把重要项目交给他们。这些人在他们之下也会有那些“能完成任务”的人，他们再把重要任务交给这些人，以此类推，一直到军队中的列兵。重要的是，那些能完成任务的人在完成任务的方式上会有更多的自由度（这可能后来成为成功的规范），而这正是这些组织运作的方式。…

> 我听过一些软件开发人员说“瀑布模型其实从未真正被使用过”。 他们的意思是，发明“瀑布模型”这个术语的人是特意告诉世界关于一种不奏效的东西。事实上，甚至回到1960年代的北约软件工程会议，他们就在讨论开发需要敏捷。 但显然，很少有大组织收到这个信息。

我是一名现职的国防部承包商（编程类），敏捷/瀑布的思维仍然适用。不同部门以及每个部门内的不同项目会有不同的规划和交付产品的方法。 然而，在我所在的部门，对“提前并出色地完成任务”有极大的重视。我很幸运能和聪明且有动力的同事一起工作，我们合作得很好，而且取得了巨大的成功。 我最大的不满，也是很多同事的共同抱怨，就是管理上的过度干预。有多个业务分析师、产品负责人、利益相关者、Scrum主管、经理等，他们基本上做着相同的工作——分配和安排任务。这使得每个项目比原本应该的难度和复杂度增加了10倍。 举个例子，就在这周： 项目A：我们正在交付一个产品。有三个经理，两个Scrum主管，多个业务…

我一直强调“软件是一种新的读写能力”。 想象一下，有一群文盲的经理，他们刚刚雇佣了一群作家来撰写一些公司政策文件。 你可以让这些经理（用雕刻/绘画/现代舞的方式）以瀑布式的方式表达他们的需求。 当然，你也可以让其中一位经理坐下来和开发人员一起，告诉他们政策每天是如何运作的，以敏捷的方式进行协作。 然而，最终你不可能事事亲力亲为，有时候公司里没有足够的人理解所需的内容，甚至无法确定那些被派驻的人员是否达成一致。 这些都是业务问题——但同时也是读写能力的问题。我们有一个读写能力普及的社会，因此有足够的读写能力的人来撰写覆盖整个公司的政策文件。 我们需要让更多的人学会编程，这样他们就能撰写出政策文件。…

与国防部项目中的敏捷相关，这里有一份来自洛克希德·马丁公司的演示文稿，介绍了他们在F-16软件项目中采用SAFe（规模化敏捷框架）的情况。虽然敏捷主义者认为SAFe是“以敏捷外衣包装的瀑布模型”，由顾问们推销，但洛克希德·马丁公司成功地将他们的周期时间从每阶段3-4年（交付给飞行测试团队）缩短到了9个月。他们正在向质量保证团队交付更小的版本，并更频繁地根据反馈进行迭代。 https://youtu.be/nvfYLZ52zX0

> 问题在于，你不能把一个流程放在软件无人机上，然后交付任何复杂度的软件。 这似乎与如今大多数科技公司的情况相矛盾，这些公司似乎痴迷于雇佣大量缺乏经验的工程师，依赖流程让他们神奇地像大师一样交付代码。 我曾在几家大型公司工作，经历了很多瀑布式开发。在日本的一家公司，我很快了解到绝不能说出“敏捷”这个词，因为它会招来经理们的恶魔。 另外，看了那份PDF，我意识到它其实是一份幻灯片演示文稿。 这份演示文稿一定非常无聊。