软件开发周期和IT核心竞争力的个人见解

我们公司连瀑布都没有。。

纯粹作坊。。。。我自己写了很多测试代码，估摸着也就我自己用得着

从十万到亿，再搞下去就是百亿访问量了。外星人都会过来访问。迭代不是处理这种问题的。
话说回来，我不知道什么叫迭代。我不需要靠这个骗钱。
换一批能干的人，啥都解决了。

用口水淬丫的。。。。。我有个项目就这么淬那个没事找抽的主的。

PS：都推倒重作过一次了，
不知道要抽接口么？
找两人去专门作这个子项目，
原项目不改直到子项目联调上就可以了。
如果再变那是子项目直接被废（也很常见），
你需要的是需求变更评审组。不是迭代

楼主的迭代与我的理解的迭代有区别啊，看了维基百科的

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

开发人员不可能知道项目的未来的需求，项目经理，业务人员都不能。因为那是未来的需求，只有在1.0的版本的使用基础之上才能体验产生的需求。
所谓现有团队的所有成员保持唯一的共同目标就是个梦想，因为你不能保证每个人的想法，需求能够在漫长的项目开发周期里面保持不变。
无论多么牛x的架构师，也不能产生历经1.0，2.0...恒久不变的架构。小修小补还好说，一般你的新版本需要对称为“架构”的部分动手，很多时候，team宁愿是重做而不是在现有的基础上修补.
以前觉得dlee的想法很好:修修补补两三年,然后推倒重来.但是如果一个项目本身开发周期就是一两年,那就杯具了.
项目经理,需求分析师唯一能做的是要求业务人员先把需求稳定下来,先让1.0版本上线,至于现有需求的不满,等2.0再说.

大家有什么好的做法,不妨提提,仅仅说scrim,xp,太空泛了.我感觉最多是管理上有点效果,技术上,还是个杯具.

我这篇文章的内在意思不是讨论迭代开发，也不是讨论你们眼里的瀑布式开发模式，更不是比较几种开发模式之间孰优孰劣。
我的看法是，我们不排斥迭代，但是要尽量减少迭代开发次数，不要使自己陷入无休止的迭代开发中让工作热情消失殆尽。这真实体现了项目经理和架构师的行业经验和技术功力，因为大量事实告诉我们，无休止的迭代开发过程，会使开发组成员疲于奔命，同时开发热情急剧下降，造成软件质量不升反降。同时由于开发人员工作热情急剧下降，软件质量下降而造成项目最终失败。除非你一次迭代周期长似1年左右，那样又和xp的精神不符，按我看仍然可以认为是迭代开发，按lss的，就不知道怎么描述好了。
如果谁对上面这些无休止迭代开发所产生出来的恶果没有深切体会，只能说开发经验实在太少，经历的项目太少，也可能没有在项目中负责过核心代码的开发。太多的人太信仰权威了，我记得以前有人质疑过xp开发中的大量testing的编写，那么我就是在质疑无休止迭代开发的恶果。要充分利用自己的经验和水平，尽量减少迭代次数。
根据前面的回帖可以看出，大部分人都还只是程序员,coder的水平，只能拘泥于具体的开发模式来看待项目开发过程，按步就班的将自己的开发模式往当前流行模式上生搬硬套。完全达不到一个项目经理，架构师看待整个项目的高度。
另外，直接回答ls的，作为项目经理和架构师，就是要对项目的潜在需求进行大量的评估，制定出高可复用和可伸缩性强的框架，而不是兵来将挡，水来土掩，这样做，是为了节省人力物力和时间。
而像ls的帖子所说的，做完1.0版，反正要换批人马重新上2.0，那样对开发人员当然没什么，最多是公司卸磨杀驴嘛，但是在公司部门层面上，显然浪费了人力物力和时间。

红色的字体部分我认为说的很好，本文的意思就是希望架构师和项目经理要尽量延长当前设计的架构的使用寿命，同时也体现了项目经理和架构师的价值所在。自然也就可以分出首席架构师，资深架构师等等不同级别了。
盖茨出任微软的首席架构师，也是这么去做的嘛，先有windows,然后.net，再然后。。。都不会是恒久不变的架构。

呵呵，potian还跟他扯这么多…
其实一个问题就戳穿一切伪敏捷伪迭代

你发布了几次？

交付周期为王。你自己闷在角落里说你在迭代你在敏捷，你从来就没交付过，哪怕内部交付也没有，甚至根本就从来没达到过可交付状态。那就很简单，你那不是迭代。结束。

我已经申明了此文不是讨论什么xp，敏捷，何来伪敏捷伪迭代，我前面回帖了多少次，迭代并不是xp开发模式专有的，迭代这个名词在计算机行业的出现至少比xp或者敏捷什么的早十年左右，难道你们以为必须和xp提倡的测试驱动，发布等等才能算是迭代么？你们仅仅只是生搬硬套迭代的概念,并没有理解什么是迭代的实质

根据上面的回复，从字里行间看出这些程序员，开发项目时几乎一点文档也不愿意写，基本也不做什么需求分析和调研，设计部分也是能省就省，项目到来，项目经理一声令下，直接就开始编码，如果编码和要求有出入，或者需求有变化，那么就套上xp提倡的“拥抱变化”，开始所谓的迭代。老板和项目经理催的也紧，那就快速发布，飞速搞定里程碑。话说这也算是正正经经的迭代开发，只是这样的迭代开发，有什么实际意义。无非是缝缝补补又三年而已。
不写文档呢，是因为这些程序员也确实极其不乐意写文档，一曰没有时间写文档，开发任务紧，其次，自己也在打小算盘，不写文档对自己编码的部分进行说明，就没人看得懂，老板就要对我有所忌惮，别搞成卸磨杀驴。这就是中国的xp开发模式的现状，一种真正的伪敏捷伪迭代。
很多项目到来，只是程序员脑子里思考设计下大致的用例图，流程图，序列图什么的，这也从另一个方面反应出本身项目也就是千篇一律的CRUD，只是不断重复再做，费时间写文档，搞设计确实也是浪费时间。
很多人做了3，4年软件开发，就只做过形形色色的税务的，金融的，汽车的，某某的CRUD，根本没有在技术方面进行深入的研发，也没有这个机会。所以越到最后，就越xp了。