瀑布開發(fā)流程更適合缺少變化,一個(gè)流程產(chǎn)出多個(gè)產(chǎn)品的制造業(yè),當(dāng)它用于開發(fā)過程不是那么穩(wěn)定,一個(gè)流程只能產(chǎn)出一個(gè)產(chǎn)品的軟件開發(fā)來說,就顯得有些力不從心,暴露出很多痛點(diǎn)。而這些痛點(diǎn),敏捷開發(fā)都可以完美解決。
瀑布式流程問題之一:版本發(fā)布所需的時(shí)間越來越長
對(duì)于一個(gè)復(fù)雜些的軟件,瀑布開發(fā)流程要完成需求、設(shè)計(jì)的時(shí)間會(huì)很長,沒有足夠的需求分析和軟件設(shè)計(jì)的時(shí)間,就無法減少后續(xù)實(shí)現(xiàn)、驗(yàn)證確認(rèn)過程中的變更,而一旦發(fā)生變更,會(huì)使得開發(fā)周期更加延長。
而在敏捷開發(fā)流程中,版本是由每個(gè)迭代完成后所獲得的增量集成在一起組成的,每個(gè)增量都能實(shí)現(xiàn)了某些價(jià)值,能夠獨(dú)立運(yùn)行。當(dāng)軟件的價(jià)值達(dá)到某種程度時(shí),我們就可以發(fā)布一個(gè)版本,一旦發(fā)現(xiàn)產(chǎn)品的價(jià)值已經(jīng)達(dá)到最大,尤其是發(fā)現(xiàn)軟件里過半的功能很少被使用的時(shí)候,就可以停止迭代發(fā)布軟件。雖然我們沒有完成所有軟件的功能,但我們可以在到達(dá)交付期限或者預(yù)算上限的時(shí)候,交付給用戶一個(gè)可用的、覆蓋軟件主要功能并且能夠解決用戶主要業(yè)務(wù)應(yīng)用需求的軟件。
瀑布式流程問題之二:無法按時(shí)發(fā)布
瀑布開發(fā)流程中,一旦出現(xiàn)重大的需求變更,將會(huì)打亂預(yù)先設(shè)想的交付計(jì)劃,軟件無法按時(shí)發(fā)布。
而在敏捷開發(fā)流程中,版本的發(fā)布最多延遲30天,因?yàn)槊看蔚淖铋L期限只有30天。當(dāng)?shù)竭_(dá)交付期限的時(shí)候,我們就可以交付已經(jīng)完成的所有迭代的增量。由于每次迭代中我們都優(yōu)先開發(fā)高價(jià)值的功能,因此在到達(dá)交付期限時(shí)我們可以發(fā)布較完整的系統(tǒng)。
瀑布式流程問題之三:在版本發(fā)布的最后階段,軟件達(dá)到穩(wěn)定狀態(tài)需要的時(shí)間越來越長
瀑布開發(fā)流程中,測(cè)試在代碼實(shí)現(xiàn)的軟件開發(fā)后期才進(jìn)行,缺陷定位、修復(fù)以及回歸測(cè)試,都可能使得軟件達(dá)到穩(wěn)定狀態(tài)的時(shí)間不斷延長。
而在敏捷開發(fā)流程中,每次迭代所產(chǎn)生的增量都是經(jīng)過驗(yàn)證和確認(rèn)的,都是完整和可用的,也就是說,敏捷開發(fā)沒有軟件發(fā)布之前的穩(wěn)定化階段,因?yàn)檐浖恢北3址€(wěn)定。
瀑布式流程問題之四:制訂計(jì)劃的時(shí)間太長,而且計(jì)劃得不準(zhǔn)確
瀑布開發(fā)流程是在需求定義準(zhǔn)確,對(duì)需求充分理解的基礎(chǔ)上,結(jié)合項(xiàng)目所能獲得的資源,考慮可能存在的風(fēng)險(xiǎn),依據(jù)以上的估計(jì)結(jié)果來制定計(jì)劃的,它需要花費(fèi)很多的時(shí)間,但結(jié)果卻不一定準(zhǔn)確,因?yàn)槠渲杏刑嗖淮_定的因素。
而在敏捷開發(fā)流程中,初始計(jì)劃簡化成為設(shè)定目標(biāo),我們僅需要根據(jù)要交付的功能和團(tuán)隊(duì)的速率預(yù)測(cè)交付日期和成本。我們只為每次迭代做詳細(xì)的計(jì)劃,而且我們可以根據(jù)上次迭代的結(jié)果及時(shí)作出調(diào)整,使得迭代計(jì)劃越來越準(zhǔn)確。
瀑布式流程問題之五:在版本發(fā)布中期很難做更改
瀑布開發(fā)流程在完成設(shè)計(jì)開始實(shí)現(xiàn)之后發(fā)生需求變更會(huì)給軟件實(shí)現(xiàn)帶來很大的不便,軟件很難進(jìn)行更改。
而在敏捷開發(fā)流程中,版本發(fā)布中期的概念已經(jīng)不復(fù)存在了。需求變更可以隨時(shí)提出,開發(fā)人員可以在下次迭代中滿足你。
瀑布式流程問題之六:質(zhì)量持續(xù)惡化
瀑布開發(fā)流程中,如果早期的需求、設(shè)計(jì)質(zhì)量低下,會(huì)影響后續(xù)的實(shí)現(xiàn)、驗(yàn)證質(zhì)量。惡性循環(huán)之下,軟件質(zhì)量會(huì)持續(xù)惡化。
而在敏捷開發(fā)流程中,每次迭代產(chǎn)生的增量都是完整且可用的,滿足質(zhì)量要求,軟件質(zhì)量不會(huì)出現(xiàn)持續(xù)惡化的現(xiàn)象。
瀑布式流程問題之七:死亡行軍使員工士氣受挫
瀑布開發(fā)流程在后期很容易出現(xiàn)大量的質(zhì)量問題,這會(huì)極大地影響項(xiàng)目團(tuán)隊(duì)的士氣。
而敏捷開發(fā)流程軟件質(zhì)量一直滿足要求,版本最后的穩(wěn)定化階段已經(jīng)不再需要,因此“死亡行軍”也隨之而去。
這正是:
瀑布開發(fā)七痛點(diǎn),敏捷應(yīng)用若等閑
若此觀點(diǎn)君認(rèn)同,實(shí)施敏捷應(yīng)不遠(yuǎn)
參考書目:30天軟件開發(fā)——告別瀑布擁抱敏捷,作者:Ken Schwaber Jeff Surherland,出版社:人民郵電出版社
聯(lián)系客服