反覆式開發法和漸進式開發

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

為什麼要迭代？

我們為什麼要進行反覆式開發法呢？您一定遇到過這樣情況：
“我們知道想要什麼。但你能估算出構建它需要多長時間嗎？”
“在啟動開發之前，我們必須將這些需求明確下來。”
“客戶不知道他們想要什麼”
“客戶時常改變想法”

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

迭代的依據

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

必要性：能支援使用者完成任務的最少功能特性；

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

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

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

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

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

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

為什麼要增量？

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

增量的依據

既然增量地發布軟體產品是為了應對軟體產品之外的不確定因素，那麼，我們確定增量發布版本的過程，也就是項目風險控制的過程。在確定版本計劃的時候，我們
採用什麼樣的尺度呢？考慮的太粗，我們的版本規劃就不會太準確，在項目實施的過程中，就會存在較大的風險；“那我們就多考慮點”，要想考慮的很周到，我們
必定會在規划上花太多的時間。這其中的“度”在哪裡呢？我們首先並且只會想到的就是對功能的優先順序進行排序，然後看情況，到項目工期截止的時候，我們的功
能完成多少我們就交付多少。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.