IID 與 End-to-End Story

Oct. 01 17:16~18:18

 

軟體開發，尤其是在敏捷開發中，有兩個常見的名詞：

• Iterative and Incremental Development（IID）
• End-to-End Story

這兩個名詞對於首次接觸的人，或是非軟體開發人員，有時候不太好解釋。前一陣子Teddy偶然發現在《Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous》這本書中，有一個例子可以同時用來解釋上面這兩個名詞。今天介紹一下這個例子（以下使用的圖翻拍自該書）。

***

Waterfall的作法

假設有一個專案，專案的需求是要請開發團隊畫出一幅蒙娜麗莎的畫像。在說明IID與End-to-End Story之前，先談一下如果專案採用傳統的Waterfall方式來進行會是怎樣的狀況。為了控管進度，專案經理先把畫這幅畫像的工作切成九等份，然後交給開發人員開始施工。

對於開發人員而言，反正最後專案時間到了一定要把這九份工作做完，所以除非有相依性關係，否則哪一份工作先做都可以。到了專案後期，這九份工作都分別完成。此時要開始準備整合測試，很不幸的雖然這九份工作分開來看功能上都OK，但是兜起來卻無法正常工作。因此專案後期花了不少時間在整合與除錯的問題上面，甚至影響了上線的時間。

更慘的是，等好不容易整合好，系統可以執行了，一拿給客戶看就被打槍說：「這不是我們要的功能，拿回去重做」。

***

IID的作法

IID的做法將專案開發切成若干個Iteration（疊代，或稱為反覆開發），意思是「固定時間長度的開發週期」。不同的開發方法有各自建議的Iteration長度，以Scrum為例，一般建議Iteration長度為2~4週之間，如果是XP則可能採用一週當作Iteration的長度。

假設鄉民們必須要在三個禮拜之內把蒙娜麗莎畫像給畫好，在此我們選擇一週為一個Iteration。所以到第三個Iteration的時候必須要交貨。

 

接下來討論需求切割的方式，IID的開發模式並沒有規定需求要如何切割，鄉民們也可以使用前面介紹的方法，把需求切成九等份。但在敏捷開發方法中，一般都是把需求以End-To-End Story的方式來切割。

• 身為使用者，我可以看到蒙娜麗莎畫像的線條草圖。
• 身為使用者，我可以看到蒙娜麗莎畫像的低解析度圖樣。
• 身為使用者，我可以看到蒙娜麗莎畫像的清楚圖樣。

和Waterfall方法中切割需求的模式相比較，看到這裡鄉民們應該很清楚傳統切割需求的方式，以及採用End-To-End Story來切割需求有何不同。最大的差異在於，每完成一個End-To-End Story之後，這個Story，或是說整個系統，是可以讓使用者直接操作使用的（running software的概念）。

以上圖為例，雖然在Iteration 1的時候，蒙娜麗莎畫像只完成了外框的線條，但是這還是一個完整的End-To-End Story，因為使用者這時候就可以欣賞這幅畫。相反地，在傳統Waterfall的開發方式中，必須等待所有的「元件」都組裝好之後，才可以開始使用系統。

***

最後剩下Incremental還沒解釋。Incremental是「增量」或「漸進」的意思。從上圖可知，整幅蒙娜麗莎畫像一次做一點（Incremental）、一次做一點，最後完成整個產品。但是這裡有一個關鍵因素要注意，Incremental雖然表示「增量」，但這些「增加出來的量」必須要讓原本的產品保持在隨時可以使用的狀態，否則這些「增量」只是「半成品」而已，就失去了IID的意義。

***

友藏內心獨白：這個例子真的不錯。