我知道，对我来说，我首先开始遵循项目管理的瀑布方法，然后我开始使用预测方法进行软件设计。我的意思是我们有大量的文档、UML、数据库模式、数据字典、工作流、活动图等。
在软件领域工作了 10 多年，现在我发现从响应式方法进行软件设计更加现实。我经常采用 Scrum 方法进行项目管理，并且几乎不会生成繁重的文档。我们的工作流程规范很少（尽管它们仍然有用）。这是一种更加动态的软件创建方法。当然，随着时间的推移，随着时间的推移，随着时间的推移，随着时间的推移，我们会发现我们预先计划好的新功能会发生巨大的变化，随之而来的是频繁的重构。
对我们来说最大的不同是第一种方法花费的时间更长，在软件构建世界中似乎更频繁地失败，并且几乎没有那么灵活。第二种方法提供了更大的灵活性，让我们更快地意识到失败（因此我们可以更快地纠正），并在每次迭代结束时提供某种形式的功能。
从经验中了解双方，我仍然发现很多人喜欢瀑布方法而不是敏捷方法进行软件开发。我不明白。
问题：为什么有人会在所有研究都支持敏捷的情况下使用瀑布而不是某种形式的敏捷？使用瀑布而不是敏捷的有力论据是什么？
当我开始编程时（至少使用 COBOL），瀑布是“新”方法。今天，我要告诉你我使用的是瀑布式敏捷方法。对于较大的系统，我发现瀑布式启动效果最好。不要创建庞大的文档（IMO 浪费时间），而是采取一些步骤，例如创建 UI 原型和/或用例来解决手头的业务问题。一旦我们感到舒服，我们就可以确定问题的范围并且我们有一个扎实的理解，我们就会进入敏捷开发模式。
不过，要回答您的问题，我认为瀑布存在的主要原因是很多人不喜欢变化。改变是可怕的，从瀑布到敏捷是一个很大的改变。
我认为人们仍然经常坚持瀑布的部分原因是它给人一种控制的错觉。在瀑布中，你可以做足够多的前期工作来制定一个漂亮的时间表，很好地解决你能想到的每一个突发事件，然后为业务方面的任何人提供一份详细的未来路线图，他们询问功能 X 何时会发布可用的。
问题是你几乎不能完全按照这个计划去做，而且你几乎总是迟到/放弃功能。然而，从前期来看，它看起来非常可控且易于管理。
我是敏捷的忠实粉丝，但我一直在努力解决销售和营销人员经常要求的长期路线图/预测。我认为瀑布的确定性幻觉对经理和业务人员来说是非常令人欣慰的。
我的老板告诉我。
我怀疑很多人别无选择，老老板也学不会新花样。
不偏袒任何一方，但几乎任何研究充其量都是不科学的。
你说（重点是我的）
问题：为什么有人会在所有研究都支持敏捷的情况下使用瀑布而不是某种形式的敏捷？使用瀑布而不是敏捷的有力论据是什么？
但不要链接到任何研究。
这是众所周知的极难实际测试的事情之一。你不能让两个相同的团队同时从事同一个项目，因为不存在两个相同的团队。您不能让同一个团队使用两种不同的方法连续两次完成相同的任务，而第一次不影响第二次。我从来没有听说过有人设计了可以令人信服地支持任何软件开发方法的实验（甚至统计）研究。不过，如果您有链接，我很想看一个。
缺乏真实证据，归结为个人喜好。巧克力优于香草的有力论据是什么？
我将扮演魔鬼的拥护者并声明敏捷存在缺陷的方式几乎与瀑布方法一样多。我不是喜欢瀑布方法的人之一，但我也不喜欢敏捷。
我在敏捷方面的经验并不是很积极。公平地说，我在企业环境中使用了它，它口头上支持“敏捷”，同时仍然期望我们的经理提前产生长期的里程碑和可交付成果。
然而，我发现敏捷（尤其是 Scrum）方法常常掩盖设计的主要问题。虽然瀑布给了经理一种控制的错觉，但敏捷似乎对开发团队也有同样的作用。我见过团队提出任何不在当前 sprint/iteraton 中的问题都是不受欢迎的，期望它会“及时”得到处理。它只需要忽略一些主要的设计决策，项目就可以在未来失败，而当前的迭代进展顺利，项目看起来走上了正轨。
您可以争辩说，团队不理解敏捷精神是错误的，但我希望看到更好的方法，将敏捷的最佳部分结合起来。
（至少）XP 的前提之一是改变很便宜。瀑布模型建立在改变的原则之上，任何改变都是代价高昂的。瀑布模型中的假设是，一旦编写了软件，更改它比预先投入时间来“完全”理解问题更昂贵。
经验似乎表明，要完全理解问题是非常困难的，如果采取一些预防措施（例如单元测试），更改可能会变得更便宜。因此，如果您遇到一些敏捷前提不成立的问题，其他方法可能再次变得可行。在瀑布式和敏捷之间，至少有螺旋式开发，这在某种程度上是我们实践的。
你需要有足够的预知能力来交付货物。你需要足够的反应来处理这些问题。
我曾经被困在六个月的时间来完成一个估计需要一年时间的项目，根据过去的经验，我需要两年时间。所以我花了三个月的时间研究方法论。我们使用瀑布流程的适当部分按时完成（三个月内）。
使该方法起作用的几点： - 创建使用标准，在需要时更新它们。- 构建库：做一次，做好，在不破坏现有代码的情况下修复它。- 做足够的文档。- 版本控制尽你所能。- 把事情分解；一个方法应该要么管理工作，要么做工作。- 增加内聚，减少耦合，重用。- 购买或构建您需要的工具。- 跟踪您的问题和进度。
我短暂参与的另一个项目是一个为期六个月的项目。直到它开始一年半后我才参与其中。开发负责人以极高的价格被聘用，因为他要离开退休金计划的职业生涯。在项目开始时，他问项目经理，“你希望我做对还是被动反应？” 你能猜出答案吗？我参与的那一周在周一、周三和周五实现了相同的功能。猜猜周二和周四发生了什么？
敏捷的优势在于它强调恰到好处，恰到好处。瀑布方法的优势在于它涵盖了您需要考虑的所有事情。我还没有从事一个已经完成或应该完成所有步骤的项目。我参与了许多项目，这些项目执行了本应在公司基础上完成的步骤。
标题说明了一切。（实际上：主动与被动）。为什么选择被动的方式并放弃控制，除非你没有必要？瀑布不是唯一的选择，你可以有任何你喜欢的开发过程。控制是关键。
顺便说一句，这是一个频谱，一端是瀑布，另一端是完全被动的零文档方法。如果您在顾问行业为强大的（通常是优柔寡断的）客户工作，您必须求助于反应性方法。如果您开发收缩包装软件，您可以提前计划并管理知识。一些项目还需要大量的规范和规则，而代码和修复方法并不能满足要求。对我来说，软件工程主要是关于知识管理和设计，其次是编码。
Ps 没有敏捷和固定价格这样的东西。不是以他们通常销售的方法的经典方式。请参阅http://martinfowler.com/bliki/FixedPrice.html
如果你确切地知道永远不会改变的需求，如果你知道每个步骤需要多长时间，如果你知道所有资源在需要的时候都是可用的，那么你可以做瀑布并且它会起作用。但事实上，这类项目非常罕见，我想我永远不会参与其中。
在设计最终用户使用的系统时，敏捷通常效果很好，因为需求可能不正确，并且流程的很大一部分是以可用版本的形式从用户那里获得反馈。
但是，在创建与其他软件接口的软件时，通常可以非常清楚地解决需求。在这种情况下，确保您有一个非常清晰和准确的规范，单元测试通常更有效率。在这个模型中，您还可以生成相当好的工作估计，并且使用敏捷模型会花费更多的成本。
追溯行为
如果你有一个由几十个人组成的团队，他们在过去十年中将瀑布策略改进到对他们有效的程度，你是谁进来说，“你做错了。 ..”？真的，如果它对他们有用，为什么要改变呢？是的，这只是在翻转问题，但我认为这可能是一个有效的观点。
在我的团队中，我们发现在维护项目（这是我们所做的大部分工作）中，我们正在调整或替换 like ，除了一些 UI 原型之外，并不总是需要用户输入。
在这种情况下，特别是考虑到涉及商业交易，宏观层面的瀑布方法非常适合。即便如此，我们仍然喜欢实施级别的增量/敏捷方法。
值得注意的是，我们的大多数客户都是喜欢他们的文书工作的大型笨拙组织，因此这为我们增加了更多动力，至少在他们看来是传统的。
在瀑布过程中生成的文档允许大量的 CYA。当项目偏离轨道时，您可以指手画脚。很少有高管会接受“哦好吧，我猜那个项目离我们而去！好吧，至少我们早发现了，没有伤害没有犯规！”
此外，设计文档可以自动生成测试计划，这对 QA 很有用。
It's pretty common when bidding for a contract that one of the iron-clad conditions is that you follow their "process" which on inspection is waterfall.