程讀書筆記

大部分公司仍使用傳統(tǒng)瀑布模型（或序列式開發(fā)方法）進(jìn)行開發(fā)?

我所工作過的公司，以及我身邊的朋友工作所在的公司，再加上招聘時(shí)從求職者那里所了解到的其他一些公 司的開發(fā)過程，
基本上都是使用傳統(tǒng)的軟件開發(fā)?模式?，類擬或者就是瀑布開發(fā)模式，這種模式有如下特點(diǎn)：
?

1)?將項(xiàng)目的生命周期明確地劃分為幾個(gè)階段，完 成一個(gè)階段才進(jìn)入下一個(gè)階段。

2)?在項(xiàng)目初期希望細(xì)化所有的需求，并希望在一個(gè)階段將需求固定后不再改變。

3)?在需求定義完畢后，在編碼之前進(jìn)行較詳細(xì)的預(yù) 先設(shè)計(jì)，完成所有或者大部分的設(shè)計(jì)工作才開始編碼。

4) 每一個(gè)階段需要產(chǎn)出大量的文檔作為下一階段的輸入。

傳統(tǒng)瀑布開發(fā)?模式有哪些缺點(diǎn)？

由于現(xiàn)代軟件系統(tǒng)的功能和設(shè)計(jì)越來越復(fù)雜，市場(chǎng)需求變化較快，所以?瀑布開發(fā)模式所要求的嚴(yán)格地完成一個(gè)階段再進(jìn)入下一個(gè)階段被認(rèn)為是太過理想化，原因有如下一些：

1) 現(xiàn)代大部分項(xiàng)目，寄望于在某一個(gè)階段將需求固定是不現(xiàn)實(shí)的，太多的誘因會(huì)引起需求的變化了，例如：

??? 1a)?沒有真正的用戶參與需求定義過程，定義的需求可能很難符合最終用戶 的工作習(xí)慣。

????? 1b)?就算把需求定義好給到最 終用戶，讓最終用戶去確認(rèn)，需求也有改變的風(fēng)險(xiǎn)，原因是用戶在看到可運(yùn)行的系統(tǒng)之前，一切都是假想，有不合理的地方他也不能完全看出來，我就假設(shè)這個(gè)用戶 很認(rèn)真地配合需求的確認(rèn)，并假設(shè)大部分需求能在這個(gè)階段確認(rèn)了，但一些非功能性的需求用戶是沒有辦法體現(xiàn)到的，例如性能、操作的流暢度等。?這就像給你一本iPhone的手機(jī)說明書，再給你一本其它智能手機(jī)的說明書，讓你去評(píng)價(jià)哪一個(gè)手機(jī)更優(yōu)秀，除了iPhone外觀、 界面漂亮點(diǎn)外，你可能真的看不出iPhone到底有什么突出的優(yōu)點(diǎn)值得這么多年輕人追棒，直到你真正拿在手上用時(shí)，體會(huì)了iPhone操作流暢的爽快感， 以及爽心悅目的窗口動(dòng)態(tài)效果時(shí)，你才能體會(huì)它的與眾不同之處。

??? 1c)?競(jìng)爭者、市場(chǎng)需求在不斷變化，用戶的需求也在跟著市場(chǎng)進(jìn)行變化，特 別是研發(fā)性的項(xiàng)目，“用戶”與研發(fā)部之間，不像一些非研發(fā)性質(zhì)的項(xiàng)目需求的變更有合同來約束。

?

2) 接下來的設(shè)計(jì)階段假設(shè)需求已經(jīng)確定，但如果需求在項(xiàng)目后期還會(huì)有較大變化的風(fēng)險(xiǎn)，那么早期就做較詳細(xì)和較完整的設(shè)計(jì)工作可能是不適當(dāng)?shù)摹?/p>

?

3) 那么，假設(shè)需求能夠確定，設(shè)計(jì)是否能夠確定呢？我的理解是，只有在我們對(duì)所在的技術(shù)領(lǐng)域非常熟悉的情況下才有可能，怎樣才算對(duì)技術(shù)領(lǐng)域非常熟悉呢？

我的理解是就像一些做信息化項(xiàng)目的小企業(yè)，他們?yōu)锳企業(yè)開發(fā)了OA辦公系統(tǒng)，再為B企業(yè)開發(fā)相擬的 系統(tǒng)時(shí)，所用的技術(shù)幾乎是一樣的，只是業(yè)務(wù)有一些異同而以。

但如果是研發(fā)性質(zhì)的公司，常常需要涉足一些陌生的技術(shù)領(lǐng)域，你在投入人力進(jìn)入這些功能的預(yù)研之前，你很難去細(xì)化這一部分的設(shè)計(jì)，但這 些技術(shù)的預(yù)研工作通常又需要很長的工作時(shí)程，可能需要經(jīng)歷較長的項(xiàng)目周期，所以說，要在項(xiàng)目初期就細(xì)化好完整的設(shè)計(jì)可能會(huì)事與愿違。

4)?當(dāng)使用瀑布模型（或序列開發(fā)模式）時(shí)，如果需求與用戶的設(shè)想出現(xiàn)了偏離，這 種錯(cuò)誤將會(huì)貫穿整個(gè)項(xiàng)目周期，設(shè)計(jì)受需求的影響，代碼受設(shè)計(jì)的影響，直到項(xiàng)目接近完成，將產(chǎn)品交付給用戶使用測(cè)試時(shí)，錯(cuò)誤才被用戶提出，這時(shí)項(xiàng)目已處于尾 聲，為遲已晚。

如何解決傳統(tǒng)瀑布開發(fā)模式存在的問題？

針對(duì)傳統(tǒng)瀑布開發(fā)模式?所存在的問題， 業(yè)界提出的解決方法就是應(yīng)用迭代開發(fā)方式，而敏捷開發(fā)更是在迭代開發(fā)的基礎(chǔ)上，作了進(jìn)一步的改進(jìn)，敏捷開發(fā)方法由于它應(yīng)用迭代和增量的開發(fā)模式，所以可以 看作是經(jīng)過改進(jìn)的迭代開發(fā)方法。

?

敏捷開發(fā)提出了以下的一些原則：
1) 假設(shè)需求總是會(huì)變化的，并歡迎需求的變化，因?yàn)樾枨蟮淖兓赡芤馕吨梢蕴嵘a(chǎn)品的商業(yè)價(jià)值。
2) 設(shè)計(jì)是演進(jìn)式的，并要保持簡單設(shè)計(jì)和彈性設(shè)計(jì)，以便能快速響應(yīng)需求的變化，而需求變化總是會(huì)引起設(shè)計(jì)的腐化，因此，經(jīng)常性的對(duì)代碼進(jìn)行重構(gòu)是必須的。
3) 短期持續(xù)交付可運(yùn)行的系統(tǒng)給用戶，目的是盡早取得用戶的反饋。
4) 更多原則可參考書籍：<<敏捷軟件開發(fā)：原則、模式與實(shí)踐>>。

?

近年來，隨著敏捷開發(fā)思想的提出，以及UP(Unified Process,統(tǒng)一流程) 、敏捷UP、Scrum 和XP(極限編程實(shí)踐) 等一系列的實(shí)踐方法得到應(yīng)用，迭代、增量的開發(fā)模式得到了更多的贊譽(yù)聲音，目前，最為熱門的是以Scrum和XP進(jìn)行組合的敏捷開發(fā)方式，已經(jīng)被騰訊、華 為、上海貝爾等一些大公司所采用。?

?

?

迭代、增量的開發(fā)模式 是如何進(jìn)行的？

迭代開發(fā)模式會(huì)將項(xiàng)目周期分為多個(gè)迭代來完成，每一個(gè)迭代只實(shí)現(xiàn)一小部分功能， 完成一次迭代時(shí)就將系統(tǒng)給到用戶進(jìn)行演示或測(cè)試，進(jìn)而及早得到用戶的反饋來改進(jìn)需求和設(shè)計(jì)，每一次迭代也需要經(jīng)歷需求分析、設(shè)計(jì)和編碼和測(cè)試等多個(gè)活動(dòng)， 但通常是輕量級(jí)的，項(xiàng)目的整個(gè)周期可能要進(jìn)行十多次或更多這樣的迭代。?

那么，迭代和增量開發(fā)模式又是如何進(jìn)行的呢？下面作一下簡述：
1)?? ?項(xiàng)目初期和我們現(xiàn)用的方法一樣，會(huì)定義好產(chǎn)品設(shè)想以及功能列表，并對(duì)產(chǎn)品功能排好優(yōu)先級(jí)，但與傳統(tǒng)的開發(fā)模式不同的是，這個(gè)階段不會(huì)去細(xì)化所有需求。
2)?? ?根據(jù)優(yōu)先級(jí)，挑選一小部分需求進(jìn)行細(xì)化，項(xiàng)目初始階段通常挑選高風(fēng)險(xiǎn)的、決定核心架構(gòu)的、業(yè)務(wù)性質(zhì)重要的功能需求來細(xì)化。
3)?? ?針對(duì)細(xì)化的一部分需求進(jìn)行設(shè)計(jì)和編碼，得到可運(yùn)行的軟件然后交付給用戶，或給用戶演示并收集反饋。
4)?? ?根據(jù)用戶的反饋修改需求，并提交新版本的軟件給用戶，直到用戶滿意。
5)?? ?重復(fù) 2~4，直到完成所有的功能。2~4 被稱為一次迭代，每次迭代大約需要數(shù)周，不宜太長，越短越好，每個(gè)項(xiàng)目可能要經(jīng)歷十多次迭代。
6)?? ?其它活動(dòng)略

轉(zhuǎn)載：https://blog.csdn.net/kwiner/article/details/5447647

總結(jié)

以上是生活随笔為你收集整理的传统序列式软件开发方法的缺点，以及迭代开发方法的选择的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。