在直接回答标题中的问题之前，最好先明确您想要实现的最终项目目标是什么
一个月、半年、一年后产品会是什么样子。 但现在描述一下。 这将为您提供一些视角，并设定有关可预测性、灵活性、敏捷性、上市速度和及时成本固定水平的基本期望。
是的，在今天看来，建立瀑布项目似乎是一个荒谬的想法。 尤其是如果已经无数次证明，如果您想快速对市场变化做出反应，除了敏捷之外别无选择。 但是，如果您的目标是一年后交付一款产品，其功能从一开始就已经非常清晰且受到限制，并且您的团队成员以前没有敏捷方法的经验，那么当然，保持保守并采用瀑布式方法。
并不是每一个案例都那么容易得出结论。 让我们看看如何更好地评估哪种方法更适合您的项目。
目录
瀑布是什么样子的？
瀑布项目的实际结果通常如下所示，而不是深入探讨几十年来每个人都已经知道的一些定义：
整个过程可能需要几个月到几年的时间。 正如您可以预测的那样，用户只有在该过程结束时才会看到结果。 因此，经过漫长的等待，关键时刻（或失败时刻）到来了。
如果在这么长的时间内发生了一些变化，并且最终产品看起来有点不同，那么这种情况就称为变更请求。 设计必须重新开放、返工和重新批准。 它使整个时间表又延长了一部分。 每一次改变都需要重新启动之前的整个流程。
另一方面，您有一个坚如磐石的阶段定义、每个阶段的固定预算和固定时间。 即使您必须等待很长时间才能获得第一个结果，如果一路上发生变化的机会很小，那么它仍然是一个更好的选择。
敏捷是什么样的？
现在，这就是该项目在敏捷设置下运行的方式：
这只是一个快速总结，但与瀑布的区别已经很明显了。 快速反馈、适应、及时反映当前变化的需求，在最短的时间内交付第一个有价值的产品。 这些都是你在瀑布项目中没有机会获得的属性。
敏捷与瀑布
如果没有合适的项目管理方法，项目就不可能成功。 这意味着为形成项目的团队定义流程、指标、评估和一般工作方式。
团队需要知道要遵循哪些规则、定义里程碑的内容、何时达到目标以及如何衡量和评估成功。 同时，利益相关者需要了解对项目的期望以及何时能够看到工作的第一个结果。
稍微概括一下，我们可以说在云环境中运行的项目更有可能倾向于敏捷方法（或者至少应该如此）。 使用本地基础设施的项目通常仍然更喜欢瀑布流程。 这是一个自然的结论。
云环境是从头开始构建的，以适应不断变化的环境。 它尽可能快地适应新的现实（通过各种“弹性”服务）。 本地环境通常是在一开始就预定义的。 随着时间的推移很难改变它，因此团队在项目的整个持续时间内都使用确定性变量。
敏捷与瀑布方法的总结。
功能瀑布方法敏捷方法处理用户需求变更被视为正式流程（变更请求）。 工作可能需要重做，从而影响成本和时间表。将变更作为标准流程的一部分，对成本或时间表没有重大影响。项目规划和范围从一开始就定义范围并坚持下去。 阶段是严格的，并遵守最初的计划。对最终产品有清晰的愿景，但允许更改。 工作被组织成冲刺，任务的完成方式具有灵活性。项目进度跟踪跟踪每个阶段的进度。 一个阶段的延迟可能会影响整个项目时间表。在每个冲刺结束时通过演示会话跟踪进度。 专注于可行的产品。团队协作不同的人在不同的项目阶段，互动有限。跨职能团队，团队成员和利益相关者之间不断沟通。风险管理基于阶段进度的状态跟踪。 在遵守计划的同时回顾性地应对风险。注重主动解决团队和活动之间的依赖关系。 调整计划以消除预计风险。实施框架传统方法。需要转型实践以适应敏捷方法。 涉及改变习惯和心态。
然而，这种选择将定义项目执行属性的几个方面。
#1. 项目需求和变更管理
定义选择的最重要方面之一是如何处理用户的需求。 另外，如果以后需要更改已经商定的要求，流程是什么？
对于瀑布项目，所有需求在一开始就由利益相关者定义并签署； 如果该状态发生任何更改，项目会将其视为更改请求。 它必须再次得到验证、同意和确认。
在那一刻之前已经完成的任何工作都必须重新审视并重新开始。 成本需要重新调整（因为这是原始合同未涵盖的额外工作）。 在最坏的情况下，甚至整个项目的工期也需要延长。
通过敏捷的设置，变化是受欢迎的。 您将这些变化视为标准的日常业务。 您同意利益相关者的观点（可能是最新冲刺演示的结果），即为了维持项目的愿景，更改至关重要。 然后，您立即为下一个冲刺安排这些更改。
之前的内容也会随之改变，从那天起，团队将继续根据新的需求进行工作。 没有时间或成本损失。 你只需立即适应新的现实，并用新的计划取代原来的计划。 根本不需要特殊的变更请求管理。 这都是冲刺计划计划的一部分。
#2. 项目规划和范围
正如您所期望的，瀑布项目在一开始就设置并修复了所有范围。 您围绕此范围生成项目计划。 然后，将项目持续时间划分为特定阶段（通常是分析、设计、开发、测试、部署、支持和维护），并围绕这些阶段修复团队和资源。 对于项目时间表的大部分时间，您的主要目标是在成本和时间安排方面尽可能坚持原来的计划。
敏捷项目有最终产品的愿景，而不是硬性计划。 最终状态是明确的，但到达该状态的路径可以自由改变。 此外，项目时间表仍然是根据对需求的初步估计和项目团队的容量负载经验来定义和商定的。 该计划没有单独的阶段。 相反，每个冲刺本身就是一个小阶段，其中包含团队成功发布增量产品所需的所有活动。
总之，瀑布项目将这些变化视为需要解决的复杂问题（也是供应商获得额外资金的机会）。 相比之下，敏捷项目将变更视为正常业务，没有额外的后果（除了更合适的最终产品）。
＃3。 项目进度追踪
瀑布项目跟踪项目阶段内计划的进度。 在分析阶段完成之前，设计阶段无法开始，在整个构建完成之前，测试无法开始，等等。
如果某些阶段出现延误，将会影响项目其余阶段的进度。 这就是为什么检查每个阶段内的活动并确保它们在此期间线性进展很重要。 否则，您将增加延迟特定阶段乃至整个项目的风险。
敏捷项目跟踪进度，主要是在每个冲刺结束时进行演示会议。 可行的产品是衡量进展的主要标准。 当然，您希望确保每个冲刺都以完整的冲刺内容结束。 没有或只有最少的故事会延续到下一个冲刺。
最终，如果您可以直接尝试当前的产品增量并立即向团队提供非常具体的反馈，那么更容易看到项目的整体进度。
＃4。 团队协作
这是关于严格独立的瀑布活动与敏捷团队所有各方的持续协作。
瀑布项目通常有不同的人在项目的不同阶段工作。 他们可能在某种程度上互相溢出，但他们仍然是不同的人群。 你可以说，几乎是孤岛。
敏捷团队的定义在于沟通和价值。 它还应该是一个能够执行所有产品生命周期活动的跨职能团队。 团队孤岛是你不希望存在的。 团队和外部利益相关者之间不断的来回沟通是成功敏捷项目的基本定义。
＃5。 风险管理
显然，您希望有一个流程来跟踪项目在其时间表内可能带来的任何风险、问题或任何类型的障碍。
对于瀑布项目，这转化为项目当前阶段的状态跟踪。 标准的类似信号量的状态报告将显示绿色（一切正常并且符合计划）、黄色（一些重要问题已经到位，但仍然清楚地了解如何解决它们）或红色（意味着项目存在严重问题，可能会影响原始时间表或预算）。
敏捷项目在这里也有所不同。 你并没有真正跟踪目标的进展情况。 相反，您可以解决不同团队和活动类型之间的依赖关系。 目标是确保没有团队在等待另一个团队进行进度活动。
当然，风险可能会出现，但解决方案必须改变未来的计划，使风险消失，而不是在保留原来计划的情况下找出风险的解决方案。
换句话说，项目的敏捷设置使用一切可能的方法来改变计划，以避免面临预计的风险，这意味着风险管理是主动的。 对于瀑布项目，您会回顾性地应对风险，并在坚持原计划的同时尝试在最短的时间内解决它们。
＃6。 实施框架
瀑布项目的实施策略显然比敏捷项目的问题要少。 通常，瀑布方法是人们已经实践多年的现状。
另一方面，项目需要敏捷的转型实践来改变他们的习惯、心态和工作方式。 这是一个困难且往往也是相当持久的过程。 公司正在投入大量时间和资源来教导人们适应敏捷流程。
快速适应客户不断变化的需求所带来的好处是显着的，但改变人们的思维方式和整体工作环境是最困难的部分。
大多数时候，这也是保持市场竞争力的唯一途径，因此对于那些成功的人来说，这种权衡会带来巨大的成功。
最后的话
让我们明确地说一下。 除非您有一个非常保守的客户，没有很大的动力快速向生产交付结果（无论他们出于什么原因），否则您最好的选择是从一开始就开始对敏捷团队进行建模。 在当今世界，这确实是理所当然的事情。 即使在传统的本地系统设置的情况下也是如此。 特别是如果团队是新的或由原来的人员从头开始，那么转变流程以与敏捷方法保持一致仍然有意义。
话虽如此，我仍然看到人们拒绝遵循这种敏捷流程或任何其他设置但严格按阶段特定的工作组织的项目。 他们遵循通常的方式，在特定的时间和预算内承包工作。 然后，他们期望项目将遵循此设置，而不会偏离计划和资金（产生各种结果，通常不是好的结果）。
这是他们有权做出的决定，但最终，有了这样的决定，他们也决定留在过去。 它可能在未来一段时间内对他们有用，但它不再起作用只是时间问题。
接下来，查看有关敏捷测试生命周期的详细文章。
