瀑布模型測試vs敏捷有什麼優點嗎？

Question

我已經讀了很多關於敏捷和瀑布的信息，我只是想不出爲什麼今天有人應該做瀑布的任何原因。我特別關心測試過程。 我錯過了什麼，是否有一些我忽略的明顯優勢？

Answer 1

還有一些情況，瀑布是適當的。典型的例子包括軍事，太空，醫療和安全關鍵系統，如飛行控制軟件，您絕對需要先詳細確定規格，開發它，然後徹底測試整個產品。

敏捷適用於大多數業務和產品軟件（即構建的大多數軟件），因爲它允許用戶從一個粗略的想法開始，並隨着時間的推移對其進行細化。如果他們的網站或內部業務線應用程序在一些迭代中不完全正確（或者存在缺陷），那麼它通常超過了從可以工作的位快速提供的業務價值。你不想從一個粗略的核電站控制器系統的想法開始，隨着時間的推移對其進行改進。

使用純瀑布的權衡是在這些場景中開發軟件的成本要高出幾個數量級。然而，成本效益仍然有利，因爲您無法支付（比如說）您的航天器在軌道中途遇到空指針異常。

當然還有灰色陰影。在瀑布框架內使用敏捷技術是可能的（參見RUP），並且可以在純瀑布和純敏捷之間放大和縮小平衡。

Answer 2

瀑布模型發展的主要優點之一是它已被用於多年和多年的發展。有用。儘管有很大的轉變和關注敏捷，瀑布是一個非常明確的過程，每個部分都有起點和終點。

隨着敏捷編程的引入，很容易看到瀑布的下降以及它如何不適應當今編程的需求。

只要你非常小心，提前計劃和充分測試，我會說敏捷測試可以和瀑布一樣有效，甚至更有效 - 當測試引發一些可能導致錯誤的錯誤時，使用敏捷確實更容易設計改變你的方式。

要考慮的另一件事是開發使用測試驅動開發。 http://en.wikipedia.org/wiki/Test-driven_development

Answer 3

外包

我看到很多企業堅持瀑布的外包項目。談到定價報價時，大多數供應商都會非常具體。瀑布很適合這種模式 - 你交出你想要的東西，他們生產它。我不是這樣的粉絲，但我可以理解執行這種方式的理由。我認爲大多數外包公司最終會找到一種變得更加靈活的方式，因爲它變得更加符合行業標準。

Answer 4

問題的答案取決於您在項目中使用何種開發方法。它是敏捷的嗎？是瀑布/等等。在過去的三到四年裏，我參與過只涉及敏捷或只有瀑布的項目，所以將它們作爲我的參考點。 如果項目需求不斷變化，我們絕不應該選擇瀑布設計，因爲瀑布方法假設設計/分析等已經完成，而如果我們選擇敏捷，則基於增量方法，我們將項目分開隨着我們的發展，我們可以將它們轉化爲增量式故事並進行構建/測試，所以如果需求發生變化，它不會涉及開發人員和測試人員的大量重新工作。例如，假設我們必須創建四個新的網頁作爲我們項目的一部分，那麼瀑布會假設他們的設計等已經完成，並且一旦所有四個頁面都開發完畢，就會開始測試，而發生敏捷的事情是我們第一次開發一個頁面並交給QA進行測試[手動/自動化]，等等。因此，我們可以看到，除了在開發時發現功能缺陷/錯誤之外，敏捷還增加了我們項目的價值，不會因爲需求變化而變得敏感。