現代越形複雜資訊系統的開發，尤以要應付快速變動性的議題，幾乎所有的主流開發流程，包括 UP (Unified Process), XP (eXtreme Programming), Agile 等不論重、輕量型的流程方法論，均一致強調反覆 (Iteration) 與 漸增 (Incremental) 開發的必要性。 關於反覆式與傳統瀑布式 (WaterFall) 開發的比較說明，請參考先前我寫過的一篇：「從軟體架構師(Architect)的觀點來看軟體開發流程」。
I&I (Iteration and Incremental) 的開發模式，已逐漸成為軟體開發的最佳實務 (Best Practice)。 但是， I&I 開發模式的實踐與否，只有在軟體開發團隊的內部才知道；對於客戶單位，他們是不知道，也不可能瞭解委外軟體廠商，內部是運用什麼樣的開發模式。
所以，外包的委外軟體開發專案，若是使用 Iteartion 的開發模式，該如何計價收費？ 或者，某大型公司的 IT 單位，規範了外包軟體廠商，必然要遵循該公司所制定的開發流程綱要。 這兩個可以說都是相當奇怪、卻也常見的問題與現象。
我先說明第二個那個怪現象‧‧‧
IT 單位規範外包廠商的開發模式，一點意義都沒有。 因為，客戶根本看不到委外廠商內部是如何開發的。 即使你強調希望委外單位能走 I&I 的模式，但是，他要掛羊頭賣狗肉，你也沒轍，因為，從最終產出 (Artifacts)來說，你根本無法知道委外單位是採取何種開發模式來完成的。 客戶單位只能要求說，委外單位要能在毎一個議定的階段時間，要能達成分次交付的產出甚或可以早些釋出 (release)、可以完整被執行的功能案例。
客戶單位所制定每一個該付交產出的階段時間，這個應該是稱之為 "Milestone (里程碑)"，完成每一個階段的交付，也可以及早瞭解委外單位的釋出品質，或作為下一次交付的回饋 (Feedback)：而若是要求儘早能看到可被執行的部分功能案例(或模組)，這稱之為 "及早釋出(Early Release)"。
再回來討論第一個問題，採用 "Iteration" 開發模式該如何計價？
前述提及， "Iteration" 這個字眼，只有被運用在軟體開發團隊內部。一個功能案例，如以 "使用案例 (Use Case)" 或 "小型模組" 為開發單位；每一個開發單位切分了兩次以上的反覆 (Iteration)，每一次的反覆，都由 PM (Project Manager)來評估決定，是否有達成該反覆的期望要求。 而到最終的反覆結束後，才算真正完成一個開發單位所交付的功能。
所以，無論團隊內部規範了多少次的反覆，客戶單位要看到的，永遠都是最後一次已經被驗收確認可被執行的功能案例。 反過來說就是，只要是那個功能案例 (或模組)一經被客戶單位驗收確認，那就是稱之為 "釋出 (Release)"。 而 "釋出" 功能案例是已經完整且可以被正確執行無誤的應用程式。
所以，要能分清楚 "Iteration" 與 "Release" 的差異：
- "反覆 (Iteration)" 是用在開發團隊內部的術語。是 PM 用以調和應變的一種方法，以及掌握開發節奏的一個開發計量單位。
- "釋出 (Release)" 則是客戶單位已經接受來自開發團隊所交付、可以被完整執行的功能案例。每一階段的釋出，都包含了不同的功能案例。
那麼，有沒有可能客戶單位要求早一些釋出部分優先權較高的功能案例？ (例如，一年期的系統開發，客戶單位規劃了三個功能模組，而要求第一個模組要在專案進行後的第四個月完整交付。) Yes，這是會的，而且是合理的，比較可以保障客戶單位所要求的系統品質。
至於如何計價收費呢？ 老實說，我倒覺得這與技術面或專案管理面實在關係不大。 最重要的應該還是在於：如何建構好與客戶的關係以及相互的信賴吧。