《需求設計：建構使用者想要和需要的産品》——3.6 疊代

本節書摘來自華章計算機《需求設計：建構使用者想要和需要的産品》一書中的第3章，第3.6節,作者： [英]　克裡斯·布裡頓（chris britton） 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

疊代可以分為三種：

1.系統測試疊代（systems test iteration）。每位程式員都有一些工作要完成，他們對寫好的代碼進行本地測試（例如，在程式員自己的計算機上測試），然後将其載入系統測試環境之中。接下來，執行新版的系統測試。此時我們有可能會發現一些版本不比對的問題，也有可能探查出程式員之間對工作的一些誤解。頻繁地進行系統測試疊代，可以盡早消除這些問題，進而使項目能夠更為順暢地推進。

2.設計疊代（design iteration）。我們有時會把新的系統測試疊代所産生的成果，展示給利益相關者看。他們看完之後，有可能提出要對設計進行修改。如果采用情境驅動設計來制作這個項目，那麼這樣的改動一般來說是比較小的。如果改動幅度确實很大，那我們可以回到情境設計層面來分析利益相關者所提出的改動要求，并檢視将要改變的這些任務之間，具備什麼樣的依賴關系。對于任何一個大型項目來說，我們頂多隻會把新版本展示給其中一小部分利益相關者去看。我們有可能要在不同的時間把應用程式分别展示給這些利益相關者，然而有些場合需要一些判斷力，例如，如果你意識到這些利益相關者會産生意見分歧，那麼你就應該把新版本同時展示給雙方看，以免出現其中一位要求這樣做，而另外一位卻要求那樣做的尴尬局面。

3.使用者疊代（user iteration）。這指的是向終端使用者釋出産品。有些時候，在釋出終端使用者版本之前，必須先進行硬體安裝/教育訓練。此外，很多使用者都不希望應用程式變化得太過頻繁，是以要確定新舊版本之間不會差得太遠。我們不應該草率地進行使用者疊代。

這些疊代可能會對目前所要管理的系統測試版本數量提出一定的要求。我們可能需要維護程式設計團隊所使用的最新版本以及最新的穩定版本，需要維護展示給利益相關者的最新版本，而且也需要維護釋出到生産環境之中的最新版本。此外，或許還有其他一些版本需要管理。管理這麼多的版本，是很耗費時間的，尤其是我們需要把同一個bug的修複更新檔，推送到多個版本之中。

從前有很多人讨論過疊代的時機與頻率問題。筆者認為，與利益相關者和使用者有關的疊代，通常是由外部事件所驅動的，它們的發生頻率，不像開發團隊所期望的那樣高。但筆者堅信：當我們可以看到整個設計的全貌時，最好是應該對疊代進行管理。這使得我們可以更好地安排各種特性之間的優先順序，并且更好地觀察出各項變化之間依賴關系，進而能夠将其更為明智地歸入不同的特性集之中。