【51CTO.com快譯】眾所周知，在一個軟件開發(fā)項(xiàng)目開始之前，項(xiàng)目經(jīng)理的工作往往是要確定在該項(xiàng)目的生命周期中應(yīng)該采用哪種開發(fā)方法。目前，業(yè)界比較流行的開發(fā)方法有兩種，它們分別是：

• 瀑布模型，一種傳統(tǒng)的開發(fā)模型與方法。
• 敏捷方法，一種較瀑布模型更新的、快速的應(yīng)用程序開發(fā)模型，開發(fā)人員經(jīng)常使用Scrum來實(shí)現(xiàn)。

如今，隨著全球各大軟件開發(fā)公司紛紛采用了敏捷方法來開發(fā)其產(chǎn)品，瀑布模型正在逐漸失去其原有的適用性。下面讓我們來深入探討敏捷方法盛行的原因、以及它與瀑布模型的區(qū)別。

各自的工作原理

瀑布模型為軟件開發(fā)提供了更為連續(xù)的方法。它會按如下順序進(jìn)行推進(jìn)：

1. 收集軟件開發(fā)的需求文檔。
2. 在需求確定完成后，開始對應(yīng)用程序進(jìn)行設(shè)計(jì)。
3. 著手開發(fā)，并執(zhí)行并行式的單元測試。
4. 通過增加負(fù)載或壓力，開展性能測試、以及用戶驗(yàn)收測試，以確保系統(tǒng)整體的穩(wěn)定性和健壯性。
5. 測試團(tuán)隊(duì)將檢測到的缺陷提交給開發(fā)人員，以著手進(jìn)行缺陷的修復(fù)。
6. 將應(yīng)用程序部署到生產(chǎn)環(huán)境中。

然而，敏捷方法卻并不遵循任何一種線性的路徑。它遵循的是迭代式的開發(fā)方法。它不會為項(xiàng)目的全程創(chuàng)建各種任務(wù)，而是分為多個迭代周期階段(Sprint)。因此，敏捷方法通常關(guān)注的是四個方面的基本價(jià)值：

• 團(tuán)隊(duì)成員之間的交互，而不是單純的工具之間。
• 更強(qiáng)調(diào)持續(xù)的工作過程，而不是包羅萬象的文檔。
• 客戶在每一次sprint中的合作與參與度。
• 快速響應(yīng)變更，而不是循規(guī)蹈矩。

需求收集階段

• 如果采用了瀑布模型來開發(fā)應(yīng)用程序，那么無論是客戶還是組織都需要事先對需求規(guī)范擁有一個清晰的理解。而一旦需求被接受了，任何一方都不可以輕易改變既定的范圍。
• 然而，在敏捷方法中，項(xiàng)目在開始時并沒有固定的需求文檔。客戶可以在每一次Sprint中提出不同的用戶故事(user stories)，而開發(fā)者的任務(wù)是完成程序編碼、并提交演示版本。如果客戶對該產(chǎn)品并不滿意，需要附加更多組件的話，那么他就可以要求對應(yīng)用程序進(jìn)行變更。可見，在處理客戶需求上，敏捷方法比瀑布模型更為靈活。

適合的項(xiàng)目

• 根據(jù)上述特點(diǎn)，如果客戶對于即將開發(fā)的軟件有著非常明確的需求，那么瀑布模型顯然是最好的方法，因?yàn)樗裱氖且环N線性的方法，并且能夠在第一個階段就將需求明確了下來。
• 然而，如果您籌備開發(fā)的應(yīng)用程序，需要在每個階段進(jìn)行演進(jìn)，并且您在項(xiàng)目中可以預(yù)見到各種頻繁的變更，那么敏捷方法則是滿足客戶需求和技術(shù)實(shí)現(xiàn)的適合方法。

產(chǎn)品對于客戶的可視性

• 在瀑布模型完成之后，應(yīng)用程序被部署到了生產(chǎn)環(huán)境中，客戶只能在項(xiàng)目結(jié)束后看到完整的產(chǎn)品。
• 而在敏捷方法中，由于持續(xù)的時間被分成了多個Sprint，客戶可以有頻繁的機(jī)會來查看產(chǎn)品，進(jìn)而做出是要接受當(dāng)前的標(biāo)準(zhǔn)、還是要執(zhí)行變更的決定。

團(tuán)隊(duì)合作

• 瀑布模型最大的缺點(diǎn)是：它不允許開發(fā)人員和測試人員之間進(jìn)行集成式的協(xié)作。測試員只有在開發(fā)階段結(jié)束后才開始接觸代碼，并著手各項(xiàng)測試工作。
• 而在敏捷方法中，測試人員和開發(fā)人員能夠協(xié)同工作。每個Sprint都有一個測試階段，而且在開發(fā)人員每次發(fā)布新的函數(shù)功能之后，測試人員都會立即進(jìn)行回歸測試。

把大任務(wù)分成小任務(wù)

• 在瀑布模型中，由于整個應(yīng)用程序是作為一個單獨(dú)的項(xiàng)目被完成的，因此整個軟件開發(fā)會變得較為復(fù)雜。特別是當(dāng)大型應(yīng)用程序進(jìn)入測試階段時，不但開發(fā)人員會產(chǎn)生等待“審判”的感覺，就連測試人員也會覺得陌生且慌亂。
• 而在敏捷方法中，一個項(xiàng)目被分成了多個用戶故事。在每個階段，開發(fā)人員和測試人員通過協(xié)同工作以了解需求，并且由客戶最后給出是否正確地完成了所有工作的結(jié)論。這些都使得各方的工作更為容易和更加快捷。

使用統(tǒng)計(jì)

一份由Standish集團(tuán)(譯者注：美國一家專門從事跟蹤IT項(xiàng)目成敗的權(quán)威機(jī)構(gòu))于2010年發(fā)布的CHAOS報(bào)告曾明確地表明：那些采用了敏捷方法的項(xiàng)目會面臨更少的挑戰(zhàn)。與遵循瀑布模型方法的項(xiàng)目相比，它們失敗的可能性會更小。

敏捷與瀑布的利與弊

瀑布式方法

作為傳統(tǒng)的瀑布模型，它在許多方面都積累了自身的優(yōu)勢：

• 通過一個可預(yù)測的、靜態(tài)的工作流，確保了團(tuán)隊(duì)能夠計(jì)算出適當(dāng)?shù)某杀尽⒁约案鶕?jù)截止日期的概念進(jìn)行合理的估算。
• 由于該過程需要各種文檔，因此各類文件線索會貫穿每個開發(fā)階段。對于項(xiàng)目團(tuán)隊(duì)而言，只要遵循過去項(xiàng)目的邏輯，就能為未來的項(xiàng)目奠定扎實(shí)的基礎(chǔ)。
• 由于流程模型較為固定，項(xiàng)目團(tuán)隊(duì)無需事先儲備與積累知識，便可根據(jù)既定的瀑布模型開展工作。

然而，該模型的缺點(diǎn)在于：

• 由于該模型是固化的，因此無論是客戶、還是項(xiàng)目團(tuán)隊(duì)，任何重大的變更都會帶來高昂的成本，畢竟整個項(xiàng)目可能會被推倒重來。
• 需求收集、開發(fā)、測試等每個開發(fā)階段都占用了大量的時間，因此項(xiàng)目干系人，特別是客戶，直到最終才能看到真正應(yīng)用效果。

敏捷開發(fā)方法

由于遵循了迭代式的開發(fā)路徑，因此敏捷方法具有如下方面的優(yōu)勢：

• 較短的開發(fā)階段，能夠使得項(xiàng)目的適應(yīng)性較強(qiáng)，項(xiàng)目組隨時應(yīng)對客戶所提出的任何重大或微小的變更。
• 客戶可以在每一次sprint期間查看到項(xiàng)目的當(dāng)前狀態(tài)，并能夠通過定期的反饋產(chǎn)生更高質(zhì)量的產(chǎn)品。
• 開發(fā)人員、測試人員、客戶三者能夠協(xié)同工作。這樣的協(xié)作式項(xiàng)目團(tuán)隊(duì)有助于個人的發(fā)展和組織的改進(jìn)。

當(dāng)然客觀地說，凡事有利必有弊，我們來看看該方法所具有的缺陷：

• 相對于文檔，敏捷方法更強(qiáng)調(diào)的是持續(xù)的工作過程。因此清晰明確的項(xiàng)目尚可接受文檔的不到位;而對于復(fù)雜的大型項(xiàng)目而言，我們?nèi)孕枰胶夂梦臋n和程序代碼之間的聯(lián)系和完整度。
• 該方法主要是針對中小型團(tuán)隊(duì)設(shè)計(jì)的。因此，團(tuán)隊(duì)中的每個成員應(yīng)當(dāng)準(zhǔn)確地明白自己的角色、以及工作的獨(dú)立性。

總結(jié)

長期從事軟件開發(fā)的項(xiàng)目人員時常會認(rèn)為：只有事先明確了客戶的需求，并采用了適當(dāng)?shù)挠?jì)劃，才能保障成功的交付。但是在我們現(xiàn)實(shí)的工作與開發(fā)任務(wù)中，只有實(shí)現(xiàn)了快速的交付，才能提高組織的盈利能力。因此，希望上述針對兩種開發(fā)方法的比較與分析，能夠幫助項(xiàng)目干系人根據(jù)手頭項(xiàng)目的具體性質(zhì)與特點(diǎn)，選擇出更為恰當(dāng)?shù)能浖_發(fā)方法。

原文標(biāo)題：Head-to-Head: The Agile and Waterfall Methodologies，作者：Arnab Roy

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】