如何使用 nTask 进行瀑布项目管理 - 初学者实用指南

我们对影响瀑布项目管理的各种因素进行了广泛的分析。 这帮助我们简化了如何使用 nTask 项目管理软件来解决此类问题。 瀑布是一种流行的 SDLC 项目管理模型。

但是，它在各个方面都很复杂。 这篇文章详细介绍了如何使用 nTask 以最大限度地提高所有面向瀑布的业务模型的生产力。 我们已经加倍努力来说明实现瀑布的各种现实用例和示例，以及如何使用 nTask 进一步简化该过程 - 等等。

关于瀑布项目管理，您需要了解什么？

瀑布方法是用于项目管理的传统和最常用的方法。 它遵循一个顺序的线性过程，这就是为什么它通常被描述为“线性顺序生命周期模型”。 顾名思义，Waterfall 专注于规划项目的生命周期，将项目划分为独特的、独立的和专有的部分：在 Waterfall 模型中，每个阶段都必须在下一阶段开始之前完成。

瀑布方法中每个独特步骤的完成都会导致项目的下一阶段，就像真正的瀑布一样。 一旦项目的一部分完成，就不能对其进行其他更改，也不能跳过一个步骤来完成下一个步骤。 因此，每个阶段都取决于前面步骤或级别的完成。 这使得瀑布模型对于要求明确且不确定性较少的小型项目最有用。 它的简单性和易于实施使其成为软件工程和 IT 项目的系统开发生命周期 (SDLC) 最流行的版本。

使用瀑布模型时，重点在于在进入后期开发阶段之前确保需求和设计符合项目的需求。

瀑布项目管理背景

来源 - Codeacademy.com

瀑布模型的起源通常归因于制造业和建筑业。 瀑布方法非常适合这些行业，因为它们遵循高度结构化的生产流程：在流程的初始阶段明确说明和概述需求，其余阶段根据需求设计。 就像在瀑布方法中一样，项目管理周期任何阶段的任何后期更改不仅成本太高，而且在某些情况下是不可能的。

Winston W. Royce 博士经常但被错误地称为“瀑布之父”，他在 1970 年写的一篇文章中首次正式描述了该过程。Royce 博士描述的是一个有缺陷的软件开发模型，因为他主张具有多次迭代或运行的模型。 他认为，如果没有多次迭代项目，第一次是原型，项目风险太大，甚至会导致失败。 在他看来，原型迭代对于更好地理解项目中涉及的需求和技术以及确保最终产品能够满足客户的需求至关重要。

补充阅读：

在您的免费项目管理工具中寻找的 7 大功能

虽然 Royce 博士归因于对该过程的第一个已知描述，但第一个已知的演示文稿归因于 Herbert D. Benington。 1956 年 6 月 29 日，Herbert D. Benington 在数字计算机高级编程方法研讨会上发表了关于 SAGE 软件开发的演讲。 在他的演讲中，他描述了这些阶段在软件工程中的使用。 仍然没有使用“瀑布”一词来描述该过程。

根据维基百科，贝尔和塞耶是第一个在 1976 年的论文中使用“瀑布”一词的人。

在 1980 年代，瀑布模型因其僵化的性质而受到强烈批评。

由于软件开发行业不断变化的需求以及瀑布模型在提供早期反馈方面的线性失败，出现了许多版本的瀑布模型。 这些版本通常统称为修改瀑布模型。

更现代的瀑布模型在之前的阶段有反馈循环，以允许修改。 瀑布模型的其他版本是彼得·德格雷斯的“生鱼片模型”（具有重叠阶段的瀑布）、V 模型或弯曲瀑布模型等。

瀑布方法论及其演变——传统的瀑布模型

自 1970 年代以来，企业和项目已采用瀑布方法进行项目管理。 使用从 A 点开始并按照顺序步骤到达终点的简单流程图不仅易于理解，而且也易于实施。 瀑布方法的各个阶段是由 Royce 博士开发的，目的是防止在项目开发周期的后期进行代价高昂的修改。 Royce 博士试图解释在他的经验中，瀑布模型是如何伴随着失败的风险的。

在 Royce 的原始瀑布模型中，他概述了这些阶段，以强调这些步骤对于大型复杂软件开发项目的重要性。 他还想指出，由于步骤的计划和执行方式不同，资源的最佳利用要求团队必须包括最能执行这些步骤的人员。

瀑布模型的典型阶段

瀑布模型的各个阶段可以根据项目框架和要求进行修改、消除或增强。

典型瀑布模型中的顺序步骤如下：

1. 构想：这个阶段是项目想法萌芽的地方。 此阶段涉及对过程的粗略评估，例如项目是否有益，所涉及的成本是多少等。
2. 启动：在构思之后，通过聘请项目团队、定义目标、范围、目的和可交付成果来启动项目。 这一阶段至关重要，因为瀑布模型强调确保需求和设计符合项目的需求。
3. 需求收集和分析：团队收集和分析所有可能的项目需求，以查看项目的可行性。 这可能还需要团队了解客户的商业模式并分析项目涉及的潜在风险。 然后在此阶段创建的所有信息都记录在需求规范文档中。
4. 设计：在此阶段，研究、评估需求规范并为完成项目准备系统设计。 确定硬件和软件要求并定义整体系统架构。 此阶段制定的设计规范用于编码阶段。
5. 实施/编码：这是根据设计规范实际开始开发/编码的阶段。 项目经理将任务委托给通常由程序员、界面设计师和其他专家组成的团队成员，使用编译器、调试器、解释器和媒体编辑器等工具。 根据项目的性质和团队规模，团队被分成更小的单位。
6. 在大多数情况下，系统首先在称为单元的小程序中开发，然后将它们集成到下一阶段。 随着每个单元的开发，对其功能进行测试，称为单元测试。 此步骤的最终输出可以是一个或多个产品组件，这些组件根据预定义的编码标准构建并经过调试、测试和集成以满足系统架构要求。 无论团队规模如何，协作和协调对于确保满足所有要求都至关重要。
7. 测试：一旦集成了所有开发的单元，就可以测试开发的整个系统是否存在任何错误。 在此阶段，还验证是否符合客户的期望。
8. 部署：完成所有测试后，将产品或流程交付给客户、发布到市场或实施。 在此过程中，应严格遵守所有流行的行业特定指南、法规和/或组织指南。 此外，必须进行实施后的验证和测试，以确认最终实施的成功。
9. 维护：如果最终用户发现任何问题，开发团队需要解决、更改或修改产品以确保其有效性。 维护期通常是指定的和预先商定的时间段。

图 2：软件开发的典型瀑布模型的基本表示

瀑布 PM 模型的流行

尽管 Royce 博士试图警告人们该模型的缺陷，为什么瀑布模型却如此普遍？

瀑布方法是项目管理中最常用的方法。 甚至在“瀑布”这个名字被赋予之前，这个模型就已经被用于各个行业。 瀑布模型流行和广泛使用的主要原因如下：

• 易于理解、使用和管理

大多数项目经理发现瀑布模型的结构易于理解和实施，因为它遵循项目的生命周期。 此外，无需培训团队并让他们熟悉瀑布方法。 整个过程的刚性不仅使实施和控制变得简单，而且减轻了项目管理的负担。

• 纪律严明

瀑布模型结构清晰的方法使其易于监控，并且随着每个阶段的完成，项目经理和客户可以看到明显的进度。 由于在需求和设计阶段花费的时间最多，因此团队错过最后期限的机会大大降低。

• 质量和详细的文档

从初始阶段开始维护和更新文档。 文件更新的严格方式确保团队和客户之间完全了解将要交付的内容。 这不仅使规划和设计更加直接，而且如果利益相关者需要查看某个阶段的更多细节，他们也会有所帮助。

• 最少的客户参与

瀑布模型的设计方式是，一旦明确定义和理解了需求，就不再严格要求客户在场。 这消除了团队的任何额外负担，并防止在项目后期引入任何新的更改，从而确保项目及时完成。

• 部门化

瀑布模型的灵活性允许团队的各个成员参与或继续其他项目的工作，具体取决于项目所处的阶段。为每个开发阶段设置预定的截止日期，项目在开发过程中按顺序移动，从而释放资源.

• 质量保险

该模型非常适用于要求明确且严格定义并且以后不可能对要求进行任何更改的项目。 此外，瀑布模型非常适合产品质量优先于时间或成本问题的项目。

为什么没有更多的项目使用瀑布项目管理模型？

根据项目的性质，瀑布模型的一些最大优势会变成其缺点。

软件开发项目的瀑布方法的最大限制是它不适合长期或大型项目。 其他缺点包括：（6）

• 几乎没有更改或修订：

瀑布模型强调明确和明确定义的需求意味着一旦最终确定，需求的任何更改不仅困难而且成本高昂。 因此，瀑布模型不适用于要求不明确的项目。 这也意味着长期项目中软件和硬件的任何变化都难以解决。 这也意味着使用此方法无法解决任何意外的项目事件。

• 产品延迟交付：

由于模型的早期阶段致力于理解需求，因此软件开发在项目生命周期的后期开始。 这意味着利益相关者直到项目生命周期的后期才能看到软件。

• 收集准确和完整的需求是不切实际的：

在初始阶段收集清晰、明确和完整的需求不仅很困难，而且对于某些项目来说也是不切实际的。 通常，客户在项目生命周期的早期并没有清楚地了解所有需求，而是随着项目的进展学习和阐明需求。

瀑布模型的现代描述

尽管存在各种缺点，但现代瀑布模型是最常见的软件开发生命周期 (SDLC) 模型之一。 瀑布模型的现代版本包含整个项目生命周期的反馈循环，包括交付后维护。

在此模型中，测试不是一个单独的阶段，而是在整个软件过程中不断执行。 这在维护阶段特别重要，以确保不仅软件按要求工作，而且任何其他要求也纳入设计。

现代瀑布模型清楚地描述了在开发和维护期间要采取的路线，直到软件退役。 现代瀑布模型消除了传统瀑布模型的许多问题，然而，它也有自己的问题。 例如，每个阶段的完成包括该阶段的完整和质量文档以及软件质量保证 (SQA) 组的批准，这也必须在任何修改的情况下完成。 坚持维护完整的文档可能会导致延误和不必要的文书工作。

用于提取现金的 ACME 超级 ATM 用例模型

简要描述;简介：

此用例描述了银行客户如何使用 ATM 从银行账户中取款。

演员：

下图显示了 ACME Super ATM 用例模型中的所有参与者。

参与者包括客户、银行系统、服务管理员和安全管理员。

前提条件：

• 银行客户必须持有银行卡。
• 与银行系统的网络连接必须处于活动状态。
• 系统必须至少有一些可以分配的现金。
• 必须提供现金提取服务选项。

另见：

5 个常见的项目管理挑战和解决方案，让他们像专业人士一样应对

基本流程：

• 插入卡
• 读卡
• 验证客户
• 选择提款
• 系统显示机器上当前可用的不同服务选项
• 选择金额
• 系统通过显示标准提款金额列表提示提款金额
• 确认提款
• 评估手头资金
• 执行操守交易
• 弹出卡
• 客户从机器中取出银行卡
• 分配现金
• 系统将请求的金额分配给客户
• 系统记录提款的交易日志条目
• 用例结束

备用流程：

备用流程包括以下场景的流程：

• 处理非标准金额的提款
• 处理不可读的银行卡
• 收据处理
• 错误处理
• 处理银行系统停止响应

异常流：

异常流包括以下场景的流：

• 评估手头资金
• 进行提款
• 服务关闭
• 处理交易调整

发帖条件：

• 自动柜员机已将卡退还给客户并将现金发放给客户，提款记录在客户的账户上。
• 自动柜员机已将卡退还给客户，且客户账户上未记录提款。
• 自动柜员机已退回卡，但未提供登记为从客户账户中提取的现金金额； 差异记录在 ATM 的日志中。
• 自动柜员机保留了该卡，客户账户上未注册提款，并且已通知客户在何处联系以获取更多信息。

公共扩展点：

没有任何

特殊要求

• 可靠的现金分配

在用于提取现金的 ACME 超级 ATM 用例模型中，所有要求都是固定且明确定义的，因此瀑布模型非常适合此示例。 一旦注意到需求，就不需要客户提供很少的反馈，并且可以按照线性顺序模式完成开发和设计阶段。 借助 nTask 等项目管理软件可以轻松管理项目，每个阶段都可以根据要求进行明确定义和细分。

用于验证客户身份的 ACME 超级 ATM 用例模型

简要描述;简介：

此用例用于验证使用 ATM 的个人（客户）是否有权使用插入的银行卡，并且与该银行卡关联的帐户处于活动状态。

演员：

参与者包括客户、银行系统、服务管理员和安全管理员。

前提条件：

• 银行卡已插入 ATM。
• 银行卡信息已读取成功。
• 客户正在与包含的用例进行对话。
• ATM 会话 ID 已创建。

基本流程

• 验证卡信息
• 系统将银行卡信息发送到银行系统
• 系统还将 ATM ID 和 ATM 会话标识符发送到银行系统
• 银行系统确认银行卡信息有效且该卡可以使用
• 验证用户身份
• 系统提示客户输入 PIN
• 客户输入 PIN
• 系统检查输入的 PIN 码是否与从银行卡读取的 PIN 码相同
• PIN 验证
• 用例结束

备用流程：

备用流程包括以下场景的流程：

• 不处理与银行系统的通信
• 不处理与客户银行的通信
• 处理非活动卡或帐户
• 处理被盗银行卡
• 处理无效的银行卡信息
• 处理未输入正确的 PIN
• 错误处理
• 处理银行系统停止响应

异常流：

异常流包括以下场景的流：

• 评估手头资金
• 进行提款
• 服务关闭
• 处理交易调整

发帖条件：

• 客户已获授权使用该卡。
• 客户已被禁止使用该卡，该卡已被没收。
• 客户已被禁止使用该卡，并且该卡未被没收。

公共扩展点

没有任何

特殊要求

没有任何

在 ACME Super ATM Use-Case Model to Authenticate Customer 中，所有要求都是固定且明确定义的。 项目规模小，可借助严格的流程轻松完成。 一旦注意到需求，开发和设计阶段就可以在线性过程中完成。 借助 nTask 等项目管理软件可以轻松管理项目，每个阶段都可以根据要求进行明确定义和细分。

行业应用——美国国防部

使用瀑布方法的广泛引用的例子是美国国防部的例子。 1985 年，美国国防部在 DOD-STD-2167A 中使用了瀑布方法，这是他们与软件开发承包商合作的标准。 尽管他们没有将他们的方法指定为“瀑布”，但美国国防部 (DOD) 仍然采用瀑布模型的基本原则。

美国政府选择了瀑布模型，因为该模型的优势完美地满足了它的要求。 联邦政府坚持严格的工程设计和优质的产品，同时对最终产品保持严格的控制。 这与包含六个阶段（初步设计、详细设计、编码和单元测试、集成和测试）相结合，再加上大量的文档、对单通道、顺序开发方法的强烈偏好以及严格的监督，使得国防部-STD-2167 瀑布法的最佳示例。

1986 年，出现了 MIL-STD 2167 修订版 A 的草稿副本，它消除了对自上而下设计的强调，并提议使用快速原型制作作为瀑布的替代方案。 这是因为瀑布模型在当时受到了严厉的批评。 尽管国防部一直在远离瀑布方法，但美国联邦软件开发和采购仍然保留了强大的硬件导向和瀑布方法。

国家研究委员会 2010 年的一份报告强调了有多少用于描述工程和制造开发阶段的术语集中在瀑布模型的元素上，例如初步设计审查和关键设计审查。 这种对瀑布项目管理方法的重视可能是因为对质量和保密性的重视。 瀑布模型的各个阶段确保不是团队中的每个成员都参与到整个项目中。

2000 年，国防部指令 (DODI) 5000.2 将进化获取确定为获取的首选方法。 但是，5000 系列法规仍然由特定于瀑布模型的术语主导。 初步设计审查 (PDR) 和关键设计审查 (CDR) 是瀑布模型的商标，为每个程序规定。

瀑布项目管理模型适合您吗？

尽管有许多缺点和限制，但瀑布模型至今仍在使用。 然而，没有一种项目管理方法适合所有业务的需求，即使是同一业务处理的所有项目也不行。 因此，它是否是满足您项目需求的理想模型取决于多种因素。

由于业务因类型、规模、行业和许多其他因素而异，因此项目也是如此。 企业应该学习这些方法、它们的用途和应用，并根据以下变量为它们决定最佳方法，而不是寻找最好的方法：

• 组织目标
• 核心价值
• 项目限制
• 项目利益相关者
• 项目规模
• 项目成本
• 承担风险的能力
• 需要灵活性

瀑布模型被最终产品需求固定但时间和金钱可变的企业使用。 瀑布模型允许项目经理多次启动同一个项目，直到达到预期的结果。 没有多少企业会发现瀑布方法的内置机制来调整和重新考虑他们的方法，直到达到理想的最佳结果。

瀑布方法非常适用于具有明确理解、固定和记录的需求、易于理解的技术工具、架构和基础设施、获得具有所需专业知识的充足资源、稳定且定义明确的产品和较短生命周期的项目。 瀑布模型的线性方法不允许发现或对初始产品需求进行任何更改。 对需求的任何更改都需要项目必须返回到第一阶段，并且整个过程重新开始。 在许多行业中，这可能是一个严重的问题，其中大多数行业都在严格的时间表上工作。

下表非常有用。 看一看。

表 1：瀑布模型要求

项目管理方法对于当今的企业至关重要。 通过为您的业务使用合适的风格，您可以改变团队协作、处理任务和完成项目里程碑的方式。

软件行业应用

当产品的需求明确定义时，瀑布模型广泛用于软件行业。 根据 Royce 的说法，最简单的程序只需两步即可完成：分析和编码。 然而，对于更复杂的项目，可能需要更多的规划。

任何软件开发的第一步都是创建功能规范。 要使瀑布模型有效，重要的是这些规范必须经过精心规划和明确定义。 这将涉及与业务专家交谈并检查当前由手动或遗留计算机系统提供的业务流程，以更好地了解业务流程。

另请参阅：JIRA 是当今市场上适得其反的项目管理软件吗？

记录要求时，必须由业务专家和客户确认。 当功能规范最终确定时，需求的最终副本被起草并锁定。

接下来是制作非工作原型应用程序以及用户界面。 这有助于客户以及开发人员了解产品的功能。 一旦这个阶段完成，软件的开发就开始了。

当应用程序完成并经过测试后，将发布一个 beta 版本并提供测试。 发现的任何错误都会迅速修复。 当不存在重大错误时，该应用程序可以作为 1.0 版上线。

汽车行业应用

在 Royce 博士于 1970 年发表论文之前，建筑和制造等行业一直在使用瀑布模型。汽车行业的组装和制造过程是刚性的，一旦工厂建成，几乎不需要调整。 因此，在建立工厂之前讨论和解决主要要求，并牢记这些要求，设计和生产过程。

组装过程本身遵循一系列必须执行的任务，否则整个过程就会崩溃。 只有一个阶段完成后，该过程才能进入下一个阶段。 对要求的任何更改都可能需要对流程进行彻底检查，并且需要额外的时间和金钱。

SDLC中的nTask与瀑布

一旦您确定瀑布模型是最适合您需求的模型，您必须考虑使用基于云的协作项目管理系统，例如 nTask。 无论您使用何种项目管理方法，nTask 等协作工具都是专门为提高团队的生产力和效率而设计的。

借助 nTask，您可以轻松管理各种规模的项目、分配和委派任务、实时共享文件和信息，并满足您的所有项目管理需求。

决定尝试瀑布方法？ 现在您已经了解了此方法中文档的重要性，您知道第一步是找到一个平台来跟踪所有必要的任务并与您的团队共享它们。

从您收集需求到测试阶段，nTask 都可以提供帮助：

• 管理并清楚地概述每个阶段的持续时间和涉及的利益相关者。
• 与所有相关利益相关者实时收集、讨论和记录所有需求。 使用 nTask，下一阶段将仅在前一阶段完成后才开始，然后只有完整的文档和批准。
• 根据最终确定的要求为您的团队创建工作流程。 nTask 允许您清楚地查看项目的进度，并允许您对瀑布模型的每个阶段中的每个任务提供反馈。
• nTask 可以轻松地与整个团队或团队的一部分进行协作和沟通。
• 在 nTask 的帮助下，为瀑布模型的每个阶段制作、维护和共享完整的文档很容易。 您可以控制谁可以查看文档，以便仅与团队成员共享相关信息。

虽然在这一点上我们讨厌切断，但这是一个两部分的帖子。 如需进一步更新，请将此页面添加为书签，并且不要忘记在一两周后跟进。 到目前为止，如果您有任何要分享的内容，可以通过下面的评论部分进行分享。 或者，您可以通过[email protected] 向我们发送电子邮件。 我们很乐意回复您。

另请阅读：

• 2022 年 21 款最佳免费生产力应用程序
• 2022 年用于个人任务管理的 23 个最佳待办事项列表应用程序
• 2022 年项目经理的 10 项基本项目管理技能
• 完成工作 (GTD) 方法和 14 个最佳 GTD 应用程序和工具
• 提高团队生产力的 19 大时间跟踪软件
• 2022 年最适合初创企业的 27 款任务管理软件
• 2022 年 36 款最佳免费生产力应用程序
• 2022 年 30 款用于个人任务管理的最佳待办事项列表应用程序
• 2022 年适用于敏捷团队的 22 个最佳免费项目管理工具
• 管理虚拟团队：挑战、技巧和虚拟团队管理工具
• 47 条最佳团队合作名言，以庆祝合作和激励