項目中最重要的是什麼？

比方說，任何項目都可以分為兩個關鍵階段：規劃和管理。但是，任何項目中最重要的元素都是其結果。無論您使用何種軟件開發方法，最終的結果都是衡量所有已完成的工作。

敏捷方法與瀑布模型

在本文中，我們確定了兩個著名的項目管理方法的主要特徵以及敏捷和瀑布模型之間的區別。使用帶有甘特圖的友好項目調度軟件，可以很容易地定義每種方法的優缺點。

如果您對這些方法只有一般性和膚淺的意見，您可以找到所有細節，研究敏捷項目管理方法的主要優點和瀑布方法的特點。

如果簡要回憶：

瀑布項目方法論是一種模型，其中產品生命週期的每個階段都按順序進行。這些進展像瀑布一樣穩步向下流過這些階段。

敏捷軟件開發方法是提出順序，線性和迭代方法的模型。

兩種最基本，最流行的方法是：

1. 瀑布:(  Waterfall），這可能更恰當地稱為“傳統”方法，而且
2. 敏捷 (Agile)： 一種特定類型的快速應用程序開發，比瀑布更新，但不是新的，通常使用Scrum實現。

這些都是可用的，成熟的方法。長期參與軟件開發項目，我想到了每個項目的優缺點。

瀑布方法論

瀑布是軟件開發的線性方法。在這種方法中，事件的順序如下：

1. 收集和記錄要求
2. 設計
3. 代碼和單元測試
4. 執行系統測試
5. 執行用戶驗收測試（UAT）
6. 修復任何問題
7. 交付成品

在真正的瀑布式開發項目中，每個項目都代表了軟件開發的一個獨特階段，每個階段通常在下一個階段開始之前完成。每個之間通常還有一個階段門; 例如，在設計開始之前，必須由客戶審查和批准要求。

瀑布方法有好處和壞處。在積極的一面：

• 開發人員和客戶就開發生命週期早期將交付的內容達成一致。這使得規劃和設計更加簡單。
• 由於工作的全部範圍是事先已知的，因此更容易衡量進展。
• 在整個開發過程中，團隊的各個成員可以參與或繼續其他工作，具體取決於項目的活躍階段。例如，業務分析師可以了解並記錄需要完成的工作，而開發人員正在開展其他項目。在編碼過程中，測試人員可以根據需求文檔準備測試腳本。
• 除了審核，批准，狀態會議等，在要求階段之後不嚴格要求客戶在場。
• 由於設計是在開發生命週期的早期完成的，因此這種方法適用於必須設計多個軟件組件（有時並行）以與外部系統集成的項目。
• 最後，基於對所有軟件可交付成果的更全面理解，可以完全和更仔細地設計軟件。這提供了更好的軟件設計，減少了“零碎效應”的可能性，這是一種開發現象，可以在定義代碼片段時發生，並隨後將其添加到可能適合或不適合的應用程序中。

以下是 使用純瀑布方法遇到的一些問題：

• 幾乎總是不足的一個領域是要求 (Requirements) 的有效性。在我看來，以對客戶有意義的方式收集和記錄需求通常是軟件開發中最困難的部分。客戶有時會受到細節的威脅，並且這種方法需要在項目早期提供的具體細節。此外，客戶並不總是能夠從需求文檔中可視化應用程序。線框和模型可以提供幫助，但毫無疑問，大多數最終用戶在將這些元素與書面要求結合在一起時會遇到一些困難，以便更好地了解他們將獲得的內容。
• 純瀑布開發的另一個潛在缺點是客戶可能不滿意他們交付的軟件產品。由於所有可交付成果均基於記錄的要求，因此客戶可能看不到將要交付的內容，直到它幾乎完成。到那時，實施變革可能很困難（而且代價高昂）。

敏捷方法論

敏捷是一種迭代的，基於團隊的開發方法。這種方法強調在完整的功能組件中快速交付應用程序。而不是創建任務和日程安排，所有時間都被“時間限制”到稱為“衝刺”的階段。每個衝刺都有一個定義的持續時間（通常是幾週），並有一個運行的可交付物列表，計劃在衝刺開始時。可交付成果按客戶確定的業務價值劃分優先順序。如果無法完成sprint的所有計劃工作，則重新確定工作的優先級，並將該信息用於將來的sprint計劃。

工作完成後，項目團隊和客戶可以通過每日構建和sprint結束演示對其進行審核和評估。敏捷依賴於整個項目中非常高水平的客戶參與，尤其是在這些審核期間。

敏捷方法的一些優點很容易看出：

• 客戶經常和早期有機會看到正在交付的工作，並在整個開發項目中做出決策和變更。
• 通過在整個項目中與項目團隊進行廣泛而直接的合作，客戶獲得了強烈的主人翁意識。
• 如果特定應用程序的上市時間比在首次啟動時發布完整功能集更為重要，那麼Agile可以更快地生成可在連續迭代中構建的基本版本的工作軟件。
• 開發通常更注重用戶，可能是客戶更多和頻繁指導的結果。
• 有關更多敏捷開發的好處，請參閱敏捷軟件開發的8個優點

當然，還有一些缺點：

• 非常高度的客戶參與雖然對項目很有幫助，但可能會給那些可能沒有時間或興趣參與此類參與的客戶帶來問題。
• 當開發團隊的成員完全致力於項目時，敏捷最有效。
• 由於敏捷專注於時間盒交付和頻繁重新優先級排序，因此可能會在規定的時間範圍內完成為交付而設置的某些項目。可能需要額外的衝刺（超出最初計劃的衝刺），增加了項目成本。此外，客戶參與通常會導致整個項目要求的其他功能。同樣，這可能會增加實施的總時間和成本。
• 當團隊成員位於同一物理空間時，敏捷項目中的緊密工作關係最容易管理，這並非總是可行。但是，有多種方法可以解決此問題，例如網絡攝像頭，協作工具等。
• 如果在初始架構和設計中不考慮系統的全部範圍，敏捷開發的迭代性質可能導致頻繁的重構。如果沒有這種重構，系統可能會降低整體質量。這在大規模實現中或在包含高度集成的系統中變得更加明顯。

在敏捷與瀑布之間做出選擇

老式的開發方式始於一個大型的前期設計，其中包含大量的需求，規範和設計文檔，這些文檔在編寫任何代碼之前都是一成不變的。一旦開發開始，範圍的變化就變得困難，因為每個階段都是下一階段的先決條件。因此，瀑布不適合與業務一起移動和發展。不是靈活的開發方式。

另一方面，我們擁有敏捷，這是最成功的軟件開發方法之一，因為它接受了需求和設計隨著產品開發而變化的事實。例如，企業可能認為產品的一個方面是正確的，但在與潛在客戶交談後，他們決定改變這一方面。隨著敏捷方式，即使在開發的最後階段也歡迎並輕鬆融入改變。

	瀑布	敏捷
發展	死板	靈活
處理	順序	迭代
初步計劃	精確	近似
文檔	準確	被忽視的
對變化的態度	沒有變化的餘地	打開
測試	僅限最終產品	每次沖刺後
小組	分離	跨職能
通訊	不足	面對面
客戶	不參加	參與
工作軟件	在末尾	每次沖刺後

敏捷是一種適應性的流程管理形式。企業的各個部門應將其視為實現短期，中期和長期目標的一種方式，並能夠在實現這些目標時對其進行修改。規劃，實施和回顧的簡短，時間框架的迭代過程是企業快速評估其正確或錯誤的方式，並將這些知識用於未來規劃。項目規劃和預算編制，證明可交付成果，高效率，最重要的是溝通，一旦組織進入這些流程的節奏就會受益。

Agile & Scrum Basis

• How to Maintain Transparency in Scrum?
• Scrum vs Waterfall vs Agile vs Lean vs Kanban
• What is 3355 in Scrum Framework?
• Why Scrum? How Does Scrum Overcome 8 Pain Points We Always face?
• The Best Free and Commercial Agile Tools – Every Scrum Team Needs!
• What are the 8 Wastes in Lean?
• Extreme Programming (XP) vs Scrum
• What is Timeboxing in Scrum?
• Agile Myth: Documentation and Planning not Needed?