軟體開發為什麼採用迭代

A. 迭代的方式完成軟體開發工作什麼意思

迭代是產品經理最喜歡用的詞。

其實意思很簡單，就是軟體開發無法一次性完全滿足用戶需求，可以先出一個版本，在使用過程中，對軟體進行升級維護，開發新功能，不斷的完善。說白了就是一遍又一遍的做相應的工作。最終完成一個成熟的產品。

現在市面上絕大部分的產品都是需要迭代的。這就是為什麼我們平時使用的軟體時不時就要更新一下的原因。

B. 軟體優化迭代怎麼通俗的說

通俗的講就是長江後浪推前浪，前浪被後浪取代了。
在軟體開發中，「迭代」跟「版本」有密切的關系。有些產品團隊會將迭代次數和產品發布的版本對等。也就是說，每迭代一次，發布一個新的版本。因此，在軟體開發中，「迭代」的含義就是功能、性能得不斷完善、優化，bug的不斷修復。
迭代是重復反饋過程的活動，其目的通常是為了逼近所需目標或結果。每，一次對過程的重復稱為一次「迭代」，而每一次迭代得到的結果會作為下一次迭代的初始值。資料來源於網路。

C. 開發中「迭代」是什麼意思

兩者有關，但不是一回事迭代開發是一種軟體開發的生命周期模型，與其對應的還有瀑布模型、螺旋模型等等敏捷開發是多種軟體開發項目管理方法的集合，其中保護了XP、Scrum等十幾種開發模式，這些開發方法有些共同點，比如重視響應變更，重視實現客戶的價值，重視開發人員的自身發展等等，其核心體現在他們著名的四句原則中。這些開發方法基本都傾向於採用迭代的軟體開發生命周期模型。 簡單來說，迭代模型是敏捷開發普遍使用的軟體生命周期模型，敏捷開發所包含的內容比迭代模型寬泛的多。

D. 迭代和增量

「迭代」和「增量」是敏捷軟體開發中的兩個重要概念。弄清楚「迭代」和「增量」以及其依據，我們就可以在實際的操作中有章法可循。

為什麼要迭代？

我們為什麼要進行迭代開發呢？您一定遇到過這樣情況： 

「我們知道想要什麼。但你能估算出構建它需要多長時間嗎？」 

「在啟動開發之前，我們必須將這些需求明確下來。」 

「客戶不知道他們想要什麼」 

「客戶時常改變想法」

「我雖然不知道客戶想要什麼，但我卻知道怎麼得到它。」怎麼得到客戶想要的東西呢？——迭代！我們不指望我們所構建的軟體正是客戶（或用戶）所想要的，但我們可以先構建後修改，通過多次迭代找到真正適合客戶（用戶）的軟體。當然，我們必須保證我們初次確定的方案是正確的、行得通的，那麼後繼的迭代就是反復求精的過程，是不斷地對備選方案改進並選擇更優方案的過程，是以更優方案取代之前勉強行得通的方案的過程。

迭代的依據

迭代開發的過程就是對軟體功能不斷細化的過程，所以，迭代的依據就是「功能細化原則」：必要性–>靈活性–>安全性–>舒適性/趣味性。

必要性：能支持用戶完成任務的最少功能特性；

靈活性：支持用戶使用多種方式完成任務或者支持用戶做出額外選擇的功能特性；

安全性：為了避免用戶犯錯，確保用戶在軟體使用過程中所做操作安全的功能特性；

舒適性/趣味性：就是可以使用戶更簡單、更快捷、更有趣地完成任務的功能特性。

每個迭代可能包含多個用戶故事，但是在同一個迭代中，我們對每個用戶故事開發的完善程度是不一樣的。如下圖所示：

隨著軟體開發工作的深入進行，我們會在每個用戶故事中發現更多的功能可能是舒適性/趣味性方面的功能，也可能是必要的功能。或者，在軟體開發的過程中，競爭對手的軟體產品有了新的功能、市場銷售情況有了新的反饋、用戶有新的需求等，我們需要不斷地豐富、細化我們的軟體所支持的用戶故事，增加/改善新的功能。經過多次迭代，我們就可以完成所有的功能，從多個層次（必要性、靈活性、安全性、舒適性/趣味性）滿足用戶需求、支持用戶故事。

在迭代過程中，功能的不確定性逐漸減小，我們對功能的描述越來越明確。

為什麼要增量？

不論是哪種類型的軟體，其業務目標或用戶（用戶目標）一旦確定下來，我們都會為此准備好「理想」的解決方案和實現手段。但是，項目工期是有限的，資金預算也是有數的，人手也不可能無限增加。為什麼項目工期總是很短？資金緊張？人手不夠？因為我們「理想」的解決方案是需要很大的代價的！並且，「理想」的解決方案也有很大的風險：在這么漫長的「完美」解決方案實現過程中，市場情況、用戶需要等外部因素都會發生改變；不及時發布、不從市場/用戶處得到及時的反饋，我們「理想」的解放方案是否真的完美也就無法得到驗證。如果說迭代開發是為了應對軟體產品內部的不確定因素的話，那麼，增量地發布軟體產品，為的就是應對軟體產品之外的其他不確定因素。

增量的依據

既然增量地發布軟體產品是為了應對軟體產品之外的不確定因素，那麼，我們確定增量發布版本的過程，也就是項目風險控制的過程。在確定版本計劃的時候，我們採用什麼樣的尺度呢？考慮的太粗，我們的版本規劃就不會太准確，在項目實施的過程中，就會存在較大的風險；「那我們就多考慮點」，要想考慮的很周到，我們必定會在規劃上花太多的時間。這其中的「度」在哪裡呢？我們首先並且只會想到的就是對功能的優先順序進行排序，然後看情況，到項目工期截止的時候，我們的功能完成多少我們就交付多少。Yes，我們大多數的軟體項目就是這么死的，都是在產品發布日的時候給它開追悼會！

按重要程度辦事，有錯嗎？讓我們打個比方吧，我們要造一輛轎車。先對轎車的功能物件排序：發動機、車底盤、傳動軸、車輪子、剎車、方向盤……。車迷朋友們還會列出更長、更詳細的按優先順序排序的轎車功能清單。有半年的工期，我們頭一個月造了個發動機，不錯很好很強大的發動機，第二個月，我們不但按計劃把車底盤搞定了，還有1周的時間，我們可以提前把傳動軸也弄弄……（黑底白字的電視屏幕上淡入又淡出幾個字「4個月後……」）還有1個月就要交付我們的轎車了，我們的車輪子怎麼上不好啊？方向盤也不轉，對了，還有擋風玻璃也沒弄，車門還沒把手，轉向燈能亮，但是它們前後左右4個一起亮……馬上，半年的交付工期到了。我們「預想」的完美轎車出廠了：絕美的流線型、強勁的引擎動力、4輪驅動、XYZ安全系統，可是、可是、、、昨天說安裝的擋風玻璃怎麼沒安啊，好辦：在領導驗收之前還來得及蒙一塊塑料布！想必，這么「拉風」的轎車，定會被老闆拍死、被客戶拍死。

現在，有點明白了吧，來感覺了？對，我們可以按照重要程度來做事情，但是，在全部必要的功能全部實現之前，你我所實現的再重要的功能都無人買單，無法體現其價值。這也是在做軟體需求工作時，普遍存在的問題：功能考慮的很多、優先順序排的挺有水平、對每個功能的描述也很詳盡，但是，各個功能各自為戰、不成體系，甚至還缺少許多必要的功能，所以，我們軟體產品的用戶就因此瘋掉了，由此也引發了眾多無聊的憂國憂民的磚家們來「反思」這樣的話題：「科技創新是否真正改善了人類的生活」。（善哉，善哉，我又不小心提到「磚家」這么不吉利的人物了）

規劃版本時，在第一個版本中，我們必須實現所有的「必要性」功能，否則，我們的軟體是無法體現出價值的。在之後的每個版本中，我們都要參考「功能細化原則」，使得我們的軟體產品的所有功能都達到相同的用戶體驗水平。（關於用戶體驗的「境界」，我們會在UCD思想中作詳細的介紹）如果每個版本中的各功能的用戶體驗「境界」不一致，很容易出現「用塑料布當擋風玻璃的豪華賓士轎車」。我們可以用如下圖所示的「版本地圖」的形式來展示軟體產品增量發布的依據——版本計劃。

當然，我們也會在完成前一個軟體版本後，發現新的市場/用戶需求，新增用戶故事。增量版本發布的過程，如下圖所示：

小結：迭代vs.增量

要想比較徹底地理解「迭代」和「增量」，我們最好將其對比一下。

迭代，就是在實現軟體的每一功能時反復求精的過程，是提升軟體質量的過程，是從模糊到清晰的過程；而增量，則是強調軟體在發布不同的版本時，每次都多發布一點點，是軟體功能數量漸增地發布的過程。二者的對比如下圖所示：

This entry was posted on 星期日, 07月 26th, 2009 at 22:30 and is filed under Agile, 指導思想. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

E. 開發過程中據說的迭代是什麼意思

迭代是重復反饋過程的活動，其目的通常是為了逼近所需目標或結果。每一次對過程的重復稱為一次「迭代」，而每一次迭代得到的結果會作為下一次迭代的初始值。

重復執行一系列運算步驟，從前面的量依次求出後面的量的過程。此過程的每一次結果，都是由對前一次所得結果施行相同的運算步驟得到的。例如利用迭代法*求某一數學問題的解。

對計算機特定程序中需要反復執行的子程序*(一組指令)，進行一次重復，即重復執行程序中的循環，直到滿足某條件為止，亦稱為迭代。

(5)軟體開發為什麼採用迭代擴展閱讀

相關概念

函數

在數學中，迭代函數是在分形和動力系統中深入研究的對象。迭代函數是重復的與自身復合的函數，這個過程叫做迭代。

模型

迭代模型是RUP（Rational Unified Process，統一軟體開發過程，統一軟體過程）推薦的周期模型。

演算法

迭代演算法是用計算機解決問題的一種基本方法。它利用計算機運算速度快、適合做重復性操作的特點，讓計算機對一組指令（或一定步驟）進行重復執行，在每次執行這組指令（或這些步驟）時，都從變數的原值推出它的一個新值。

方法

迭代的方式就有所不同，假如這個產品要求6個月交貨，我在第一個月就會拿出一個產品來，當然，這個產品會很不完善，會有很多功能還沒有添加進去，bug很多，還不穩定，但客戶看了以後，會提出更詳細的修改意見。

這樣，你就知道自己距離客戶的需求有多遠，我回家以後，再花一個月，在上個月所作的需求分析、框架設計、代碼、測試等等的基礎上，進一步改進，又拿出一個更完善的產品來，給客戶看，讓他們提意見。

就這樣，我的產品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現我花了大量心血後，直到最後發布之時才發現根本不是客戶要的東西的情況。

優勢

這樣的方法很不錯，但他也有自己的缺陷，那就是周期長、成本很高。在應付大項目、高風險項目——就比如是太空梭的控制系統時，迭代的成本比項目失敗的風險成本低得多，用這種方式明顯有優勢。

如果你是給自己的單位開發一個小MIS，自己也比較清楚需求，工期上也不過花上個把月的時間，用迭代就有點殺雞用了牛刀，那還是瀑布模型更管用，即使是做得不對，頂多再花一個月重來，沒什麼了不起。