如何使用 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 條最佳團隊合作名言，以慶祝合作和激勵