瀑布與敏捷開發方法大比拼
譯文【51CTO.com快譯】眾所周知，在一個軟件開發項目開始之前，項目經理的工作往往是要確定在該項目的生命周期中應該采用哪種開發方法。目前，業界比較流行的開發方法有兩種，它們分別是：
- 瀑布模型，一種傳統的開發模型與方法。
- 敏捷方法，一種較瀑布模型更新的、快速的應用程序開發模型，開發人員經常使用Scrum來實現。
如今，隨著全球各大軟件開發公司紛紛采用了敏捷方法來開發其產品，瀑布模型正在逐漸失去其原有的適用性。下面讓我們來深入探討敏捷方法盛行的原因、以及它與瀑布模型的區別。
各自的工作原理
瀑布模型為軟件開發提供了更為連續的方法。它會按如下順序進行推進：
- 收集軟件開發的需求文檔。
- 在需求確定完成后，開始對應用程序進行設計。
- 著手開發，并執行并行式的單元測試。
- 通過增加負載或壓力，開展性能測試、以及用戶驗收測試，以確保系統整體的穩定性和健壯性。
- 測試團隊將檢測到的缺陷提交給開發人員，以著手進行缺陷的修復。
- 將應用程序部署到生產環境中。
然而，敏捷方法卻并不遵循任何一種線性的路徑。它遵循的是迭代式的開發方法。它不會為項目的全程創建各種任務，而是分為多個迭代周期階段(Sprint)。因此，敏捷方法通常關注的是四個方面的基本價值：
- 團隊成員之間的交互，而不是單純的工具之間。
- 更強調持續的工作過程，而不是包羅萬象的文檔。
- 客戶在每一次sprint中的合作與參與度。
- 快速響應變更，而不是循規蹈矩。
需求收集階段
- 如果采用了瀑布模型來開發應用程序，那么無論是客戶還是組織都需要事先對需求規范擁有一個清晰的理解。而一旦需求被接受了，任何一方都不可以輕易改變既定的范圍。
- 然而，在敏捷方法中，項目在開始時并沒有固定的需求文檔。客戶可以在每一次Sprint中提出不同的用戶故事(user stories)，而開發者的任務是完成程序編碼、并提交演示版本。如果客戶對該產品并不滿意，需要附加更多組件的話，那么他就可以要求對應用程序進行變更。可見，在處理客戶需求上，敏捷方法比瀑布模型更為靈活。
適合的項目
- 根據上述特點，如果客戶對于即將開發的軟件有著非常明確的需求，那么瀑布模型顯然是最好的方法，因為它遵循的是一種線性的方法，并且能夠在第一個階段就將需求明確了下來。
- 然而，如果您籌備開發的應用程序，需要在每個階段進行演進，并且您在項目中可以預見到各種頻繁的變更，那么敏捷方法則是滿足客戶需求和技術實現的適合方法。
產品對于客戶的可視性
- 在瀑布模型完成之后，應用程序被部署到了生產環境中，客戶只能在項目結束后看到完整的產品。
- 而在敏捷方法中，由于持續的時間被分成了多個Sprint，客戶可以有頻繁的機會來查看產品，進而做出是要接受當前的標準、還是要執行變更的決定。
團隊合作
- 瀑布模型最大的缺點是：它不允許開發人員和測試人員之間進行集成式的協作。測試員只有在開發階段結束后才開始接觸代碼，并著手各項測試工作。
- 而在敏捷方法中，測試人員和開發人員能夠協同工作。每個Sprint都有一個測試階段，而且在開發人員每次發布新的函數功能之后，測試人員都會立即進行回歸測試。
把大任務分成小任務
- 在瀑布模型中，由于整個應用程序是作為一個單獨的項目被完成的，因此整個軟件開發會變得較為復雜。特別是當大型應用程序進入測試階段時，不但開發人員會產生等待“審判”的感覺，就連測試人員也會覺得陌生且慌亂。
- 而在敏捷方法中，一個項目被分成了多個用戶故事。在每個階段，開發人員和測試人員通過協同工作以了解需求，并且由客戶最后給出是否正確地完成了所有工作的結論。這些都使得各方的工作更為容易和更加快捷。
使用統計
一份由Standish集團(譯者注：美國一家專門從事跟蹤IT項目成敗的權威機構)于2010年發布的CHAOS報告曾明確地表明：那些采用了敏捷方法的項目會面臨更少的挑戰。與遵循瀑布模型方法的項目相比，它們失敗的可能性會更小。
敏捷與瀑布的利與弊
瀑布式方法
作為傳統的瀑布模型，它在許多方面都積累了自身的優勢：
- 通過一個可預測的、靜態的工作流，確保了團隊能夠計算出適當的成本、以及根據截止日期的概念進行合理的估算。
- 由于該過程需要各種文檔，因此各類文件線索會貫穿每個開發階段。對于項目團隊而言，只要遵循過去項目的邏輯，就能為未來的項目奠定扎實的基礎。
- 由于流程模型較為固定，項目團隊無需事先儲備與積累知識，便可根據既定的瀑布模型開展工作。
然而，該模型的缺點在于：
- 由于該模型是固化的，因此無論是客戶、還是項目團隊，任何重大的變更都會帶來高昂的成本，畢竟整個項目可能會被推倒重來。
- 需求收集、開發、測試等每個開發階段都占用了大量的時間，因此項目干系人，特別是客戶，直到最終才能看到真正應用效果。
敏捷開發方法
由于遵循了迭代式的開發路徑，因此敏捷方法具有如下方面的優勢：
- 較短的開發階段，能夠使得項目的適應性較強，項目組隨時應對客戶所提出的任何重大或微小的變更。
- 客戶可以在每一次sprint期間查看到項目的當前狀態，并能夠通過定期的反饋產生更高質量的產品。
- 開發人員、測試人員、客戶三者能夠協同工作。這樣的協作式項目團隊有助于個人的發展和組織的改進。
當然客觀地說，凡事有利必有弊，我們來看看該方法所具有的缺陷：
- 相對于文檔，敏捷方法更強調的是持續的工作過程。因此清晰明確的項目尚可接受文檔的不到位;而對于復雜的大型項目而言，我們仍需要平衡好文檔和程序代碼之間的聯系和完整度。
- 該方法主要是針對中小型團隊設計的。因此，團隊中的每個成員應當準確地明白自己的角色、以及工作的獨立性。
總結
長期從事軟件開發的項目人員時常會認為：只有事先明確了客戶的需求，并采用了適當的計劃，才能保障成功的交付。但是在我們現實的工作與開發任務中，只有實現了快速的交付，才能提高組織的盈利能力。因此，希望上述針對兩種開發方法的比較與分析，能夠幫助項目干系人根據手頭項目的具體性質與特點，選擇出更為恰當的軟件開發方法。
原文標題：Head-to-Head: The Agile and Waterfall Methodologies，作者：Arnab Roy
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
