你的项目为什么不迭代？
软件开发工艺从瀑布模型转向迭代、递增、演进式模型，是过去20 多年来所发生的世界软件工程最为重大的一项管理和技术方法变革之一；如果你的团队一时还做不到敏捷，那么应该先做到迭代。
如今不但 21 世纪的敏捷方法（Scrum、XP、AgileUP、MSF for Agile、FDD、Crystal 等等）普遍采用了迭代方式，就连正宗的 CMM/CMMI 实施典范和过程（敏捷的 TSP）也采用了迭代式开发模型。当我向一些号称实施了 CMM/CMMI 的朋友们提到，CMM/CMMI 过程其实也应该或最好采用迭代式开发时，他们竟然都对此好像一无所知，一脸茫然，感到很诧异。
迭代是如此重要。可是我发现，国内很多软件项目团队至今仍然没有真正地理解和掌握好迭代开发与管理技术，尤其是真正能够做到 time-boxing（时间盒）迭代的团队好像非常少（未经科学统计）。国内的很多 IT/软件项目为什么不迭代？估计可能有许多种原因。
1）不知迭代为何物，不理解为啥要迭代。
当被问到一个软件开发项目分几步做、需要哪几个阶段时，我猜大概国内有一大半的IT/软件专业人士及项目管理人士都会回答：还用问？不就是分为需求阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、部署阶段 ... 等等这几个阶段么，简单得很！
可是，错了！这其实是一种极为常见的惯性瀑布思维。40 年的软件工程科学研究和工程实践表明，瀑布式生命周期是一种过于简单、过于理想化的模型，很难适应当代复杂多变软件项目开发的现实。很多人不了解迭代式生命周期及其重要性，可能与一段时期落后的软件工程教育、舆论环境的影响有关。
我不记得 2000 年之前有哪一本国内的软件工程教材非常深入地介绍和强调了迭代递增式开发的重要性，可能是我的记性差，反正是印象远不如瀑布模型深刻。20 年来国内的软件瀑布式生命周期模型得到广泛加强和应用，大概与这种传统教材和教育的普遍性有关。2000 年之后，情况似乎有所改善，但这方面的宣传，有关软件过程由瀑布式向迭代式这一重要转变的宣传，还是远远不够的，在人们大脑中的印象远不及铺天盖地的 ISO、软件过程改进、CMM、CMMI、软件测试、全面质量管理（TQM）、6sigma、软件项目管理、PMP ... 等等之类的潮流概念和词汇深刻。
迭代的出现比敏捷早得多。这些年，我一直向大家推荐敏捷大师 Craig Larman 和软件工程权威专家 Vic Basili 教授早在 2003 年就发表在 IEEE Computer 杂志上的着名封面文章《迭代与递增式开发简史》。有谁能想到 IID（迭代与递增式开发）竟然有近 40 年的历史？
2）把客观条件不具备作为不迭代的借口。
比如，“客户不接受迭代方式，因此我们无法迭代。”
这句话当然有一点道理，但其实软件开发团队迭代不迭代，与客户懂不懂迭代关系不大。
3）没有意识到：大量项目的失败原因其实与误用瀑布式（不迭代）有关。
近 40 年的软件工程实践表明：不迭代的项目风险非常大！
平庸的开发团队往往不能够溯源而上，理清各种因果要素之间的逻辑关系，准确找到导致项目失败的真正原因和根源，因而容易一错再错，屡战屡败。
4）认为迭代在技术上不可行。
一种经典的误解认为，由于逻辑的紧密相关性，必须要在完成全面而详尽的项目计划、需求分析、系统设计，作出周密的思考之后，才能开始编程（瀑布式），这样可以避免项目后期的程序修改，而迭代会导致程序的不断修改，是不可取的。
5）明知问题出在错误地采用了瀑布式，应该转向迭代式，却无力而改变之。
这种情况值得同情。作为研发骨干和一线或中层管理者，不少人意识到了迭代过程的重要性，也尝到了多次项目失败的滋味，深刻体会到瀑布式（或准瀑布、伪瀑布式开发）的种种弊端，可是囿于企业/组织原有的观念、制度、文化、考核等体系根深蒂固，高层领导又缺乏变革的动力和意识，导致这些有识之士无力去改变现状。
找到问题的真正根源，总比工作在自欺欺人的环境中，整日稀里糊涂地混下去要好。我很乐意作为外部第三方尽我的可能帮助这些朋友们。
