我在项目中主要使用了瀑布方法，但是现在我将眼光扩展到了敏捷方法中。到目前为止，从我读过的东西（也许我读错了东西）来看，敏捷意味着小瀑布。您不用持续一到两年的大瀑布，而是可以持续几周或最多几个月的小瀑布。
我的理解是正确的还是不仅仅如此？敏捷哲学是什么？
Answers:
简单来说，是的。仅每两周执行一次Waterfall不会使您敏捷，但这是迭代的（这是敏捷的一半）。
瀑布模型定义了阶段-需求，体系结构，设计，实现，验证（测试），验证（验收测试）和发布。在任何迭代方法中，您都将在每次迭代中经历这些阶段中的每个阶段。它们之间可能有重叠，但是您可以引出并捕获需求，采用系统的体系结构和设计以进行实施，开发新功能或修复缺陷，测试新模块，然后将其提交给客户以供接受测试和部署。
但是，敏捷不仅需要迭代和增量，还需要做更多的事情。敏捷的租户被捕获在敏捷软件开发宣言中。宣言中有四个要点：
个人与流程和工具之间的互动
您经常让个人参与。许多实施都围绕自组织和自指导的团队。几乎所有人都经常与客户或有客户声音的人互动。您不必让一组正式的程序可以遵循和使用一些工具，而是让从事项目工作的人员来驱动项目的完成方式，从而以最佳的方式完成它。
工作软件超过全面的文档
在软件项目中，主要目标是交付软件。但是，在某些项目中，浪费的文档生产没有任何价值。Scott Ambler在敏捷/精益文档方面写了一篇很好的文章。这不是要不生成文档，而是要选择可以为您的团队，未来的开发人员，客户或用户增加价值的文档。您的软件工程师不是在制作不会增加价值的文档，而是在制作软件和相关的测试。
客户合作而非合同谈判
与其预先定义条款和时间表以及成本，不如说是与客户不断努力。例如，您可能以用户故事的形式捕获需求并为其分配分数。经过几次迭代后，您便确定了速度（点/迭代），并可以确定您的团队可以在迭代中实现多少个功能。当您的客户提供有关哪些功能可带来最大价值的反馈时，他们可以随时决定何时完成该项目。频繁的交付和与客户的互动可能会发生很多事情-满足了要求，项目结束了维护并最终终止了寿命，客户发现他们并不需要他们认为的一切，因此决定结束项目，该项目失败了，客户很早就发现了这一点，可以取消它。
响应计划变更
您无需预先制定大型设计或最终计划，而必须在必须更改设计或计划时进行返工。您不断根据您所拥有的信息估算和修订估算。您仔细选择度量标准，以洞悉项目的运行状况以及何时进行内部更改。您经常向客户添加，删除需求并对其进行优先级排序。最终，您了解到变化是唯一不变的。
敏捷意味着通过迅速交付高质量，增值软件来关注人们并满足他们的需求。随着客户需求的变化，您可以适应这些需求，从而专注于增加价值。敏捷方法有一些特定的实现，但它们都以人员为中心，及时交付工作软件，并适应快速变化的环境。
我会说这是一种简单的说法。是的，当您深入研究时，它的水流很小，但是背后却有更多的东西使它起作用。改变您处理项目方式的整个方法……更不用说所需的思维方式了。
如果您认真对待敏捷，那么以下是一系列（而且很长）的网络广播，您可能会感兴趣：
忘记敏捷，请思考一下“瀑布”的含义。
在需求阶段，每个人都试图找出最终产品需要解决的问题。人们对此争论了一段时间，然后他们都签署了一系列要求。至此，您的范围已定义，已签订合同，客户可以徘徊并等待您提出满足这些已定义要求的产品。
接下来是一个（或两个）设计阶段。设计人员（可能是开发人员，也可能不是开发人员）对系统必须如何配合才能满足已签署的要求进行了争论。如果他们不太了解需求，则可能会出现问题，这可能意味着他们必须回到客户手中，可能会重新打开需求阶段（并获得另一轮批准）或至少将变更管理付诸实践。通常，设计师只是做出最大的猜测。他们可能会提出一个逻辑数据模型，以及许多描述新系统及其工作方式的UML。然后他们在上面签字。
现在，开发人员可以根据已签署的设计实际开始编码。如果他们不太了解设计，可能会出现问题，这可能意味着他们必须回到设计者手中，可能会重新打开设计阶段（并获得另一轮批准）或至少将变更管理付诸实践。设计人员可能会反过来意识到，混淆确实可以归结到需求，这意味着他们必须重新打开需求讨论，签署和进一步的变更管理。通常，程序员（迫在眉睫的最后期限）只是做出最好的猜测。他们尽力制作功能代码。然后他们将其发布以进行测试。
现在系统测试阶段开始了。测试人员根据对需求和设计的理解进行测试，并将他们认为是缺陷的内容注册到错误跟踪/变更管理系统中，从而使开发人员重新开始开发，除非他们认为问题出在设计缺陷，将其发送回设计等。最终，系统测试通过并被批准。
最后，客户返回并在新系统上进行用户接受度测试。他们在这里决定测试人员测试，开发人员开发和设计人员设计的解决方案是否真正是他们想要的。如果不是这样，您可能必须回到设计阶段，甚至重新审视需求。
瀑布背后的想法是，一旦完成一个阶段，就很难（并且非常不希望）返回。通常，不同的人会涉及不同的阶段，因此会有很多交接-每个交接都会带来很大的误解和信息丢失的风险。在客户说出他们想要的内容和何时看到已建好的内容之间还存在很大的差距，在这段时间内，实际需求可能会发生很大的变化。
敏捷方法论着重于所有有关方面之间的强有力的沟通与合作。“基于合同协商的客户协作”原则意味着您不必经历一系列的签字和移交，而应与客户一起简单地工作，每次迭代都确定了难题的要求并立即形成测试，设计和工作代码-与所有参与者尽可能直接地沟通（消除交接成本和风险）。客户可以快速测试工作代码，从而消除了时滞风险。所有活动都以协作的方式进行，而不是以向下的方式进行。
要获得有关敏捷方法论尝试方法的出色概述，我强烈推荐Allistair Cockburn的《敏捷软件开发：合作游戏》。