不但 21 世纪的敏捷方法普遍采用了迭代方式，就连正宗的 CMM/CMMI 实施典范也采用了迭代式开发模型。当我向一些号称实施了 CMM/CMMI 的朋友们提到，CMM/CMMI 过程也应该采用迭代开发，他们竟然都感到很诧异。
迭代如此重要。可是我发现，国内很多项目团队至今仍然没有真正地理解和掌握迭代开发与管理技术，尤其是真正做到 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）明知问题出在瀑布，应该转向迭代，却无力而变之
这是一种值得同情的情况。作为研发骨干和中层管理者，不少人意识到了迭代过程的重要性，也尝到了多次失败的滋味，深刻体会到瀑布式或准瀑布、伪瀑布式开发的种种弊端，可是由于公司、企业原有的观念、制度、文化、考核等体系根深蒂固，高层领导又往往缺乏这样的变革意识，导致企业中的有识之士无力去改变现状。
找到问题的真正根源，总比工作在自欺欺人的环境中，整日稀里糊涂地“混”要好。张恂很乐意作为来自外部的第三方力量帮助这些朋友。
...
为什么不迭代？读者朋友，您知道还有其他什么原因吗？
文章来源于领测软件测试网 https://www.ltesting.net/