不但 21 世紀的敏捷方法普遍采用了迭代方式，就連正宗的 CMM/CMMI 實施典范也采用了迭代式開發模型。當我向一些號稱實施了 CMM/CMMI 的朋友們提到，CMM/CMMI 過程也應該采用迭代開發，他們竟然都感到很詫異。
迭代如此重要�？墒俏野l現，國內很多項目團隊至今仍然沒有真正地理解和掌握迭代開發與管理技術，尤其是真正做到 time-boxing 迭代的團隊好像非常少。（我說的很少，只是我的印象，并沒有經過科學的統計）
當問到一個軟件開發項目，分幾步、有哪幾個階段時，我想大概國內 95% 以上的軟件專業人士及項目管理人士都會回答：不就是分為需求階段、概要設計階段、詳細設計階段、編碼階段、測試階段 ... 這幾個階段么，簡單得很！
這是一種最為典型的瀑布思維（可見教育的力量），或錯誤。殊不知，早在 10 年之前，為了配合迭代模型，RUP 就已經取消了需求階段、設計階段、編碼階段和測試階段的叫法，取而代之的是更為成熟和先進的里程碑劃分：起始階段、細化階段、構造階段和移交階段，在每一個階段中都有需求、設計、編碼和測試這四項活動。
為什么不迭代？我分析這背后可能有許多原因。
1）很多人還不知迭代為何物，不理解為啥要迭代
這可能與落后的軟件工程教育、輿論環境有關。（我說的教育是大教育，不單指學校，還包括媒體、網絡社區等大環境）
我是一名 70 后，我不記得 2000 年之前有哪一本國內的軟件工程教材非常深入地介紹和強調了迭代遞增式開發的重要性，有可能是我的記性差，反正是印象遠不如瀑布模型深刻。20 年來國內的軟件瀑布模型得到廣泛加強和應用，我想應該與這種教材和教育的普遍性有關。您還可以去查閱一下，軟件開發的國家標準（GB）推薦的是哪種方式（由于大家都熱衷與去搞 CMM/CMMI，GB 好像很久沒有更新了）。
2000 年之后情況可能有所改善，但這方面的宣傳，有關瀑布式向迭代式這一重要生產力方式轉變的宣傳，還是遠遠不夠的，在人們大腦中的印象遠不及鋪天蓋地的 ISO、CMM、CMMI、軟件測試、全面質量管理 ... 之類的籠統概念和詞匯深刻。
對于迭代開發方式的了解大概是從 1998 年之前的《微軟的秘密》開始的，2000 年之前又從 RUP 中學到了非常經典的迭代模型。
這些年，我一直向大家推薦敏捷大師 Craig Larman 和軟件工程權威 Vic Basili 教授早在 2003 年就發表在 IEEE Computer 雜志上的著名文章《迭代與遞增式開發簡史》，有誰能想到 IID（迭代與遞增式開發）竟然有近 40 年的歷史？
2）很多人沒有意識到：大量的項目失敗原因其實與不迭代有關
毋庸諱言：不迭代的項目風險非常之大！
有些團隊（比較平庸的）始終都還不能夠溯源而上，理清各種因果要素之間的邏輯關系，最終找到導致項目失敗的真正原因和根源，因而往往容易一錯再錯，屢戰屢敗。
3）很多人把客觀條件不具備作為不迭代的借口
“客戶不接受迭代方式，因此我們無法迭代�！�
這句話當然有一點道理，但其實軟件開發團隊迭代不迭代，與客戶懂不懂迭代關系不大。
4）明知問題出在瀑布，應該轉向迭代，卻無力而變之
這是一種值得同情的情況。作為研發骨干和中層管理者，不少人意識到了迭代過程的重要性，也嘗到了多次失敗的滋味，深刻體會到瀑布式或準瀑布、偽瀑布式開發的種種弊端，可是由于公司、企業原有的觀念、制度、文化、考核等體系根深蒂固，高層領導又往往缺乏這樣的變革意識，導致企業中的有識之士無力去改變現狀。
找到問題的真正根源，總比工作在自欺欺人的環境中，整日稀里糊涂地“混”要好。張恂很樂意作為來自外部的第三方力量幫助這些朋友。
...
為什么不迭代？讀者朋友，您知道還有其他什么原因嗎？
文章來源于領測軟件測試網 http://www.kjueaiud.com/