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

近日在调研/设计/开发软件时想到一个有关于软件开发方面的问题，也可以说是两种软件开发的方法。阐述如下。
抛开软件的开发过程及那些瀑布开发模式，原型开发模式，xp开发模式等等不谈。软件开发需要面对一个实际的问题就是，无论哪种开发模式，都有一个开发周期，一个客户要求的交货，验货deadline截止日期。
我个人认为，根据截止日期的不同，实际上决定了软件的粗糙程度，当开发周期相对较短时，自然而然会选择原型开发或者xp开发模式，这些开发模式当然不是软件质量的核心问题，而一些黑盒测试实际上是无法对软件真正的高可复用性，可伸缩性打保票的。笔者认为，软件质量及可复用性归根到底实际上是架构师和开发人员的经验和功力所在。否则很多开发人员把自己的产品叫做baby呢。可参见笔者的另一篇文章，软件究竟是开发出来的，还是测试出来的问题。
一个软件，我们可以根据需求，用最简单，最直接，最原始的方式去实现它，实现起来相对容易，对开发人员要求也不高，项目进度也会很快，但是软件质量首先得不到保证，软件肯定也很粗糙，耦合性较强等等弱点，在今后的进一步应用和开发中肯定会凸显出来，如果有持续需求不断加入，那么这种软件的后续维护，开发工作将是非常困难和艰巨的。这种软件的最终结果往往是一期项目结束，二期新需求到来后，一期的架构已经完全不能适应新的需求，唯一的办法就是推倒重来，这等于是做了两个项目，如果两个项目能够互不影响，分别计价，那也仅仅是对企业和个人当前利益的保证。
事实上淘宝网的架构及开发就是按照这种模式来的，如果说淘宝处于业界前沿阵地，尚没有前人的经验可借鉴，而走了不少弯路，那么如果在已有前人涉险之后，我们就不应该再犯类似的错误了。
而另一种开发方式，在拿到需求后，架构师对潜在的需求及风险等做出足够的评估和预测，同时在高可复用性，可伸缩性方面做到充分的考虑和测试，虽然说仅仅这一步就已经使项目周期会大大增长，但这一步为今后项目的平稳过渡和易维护做到了充足的保证。将一个软件的耦合性尽量做到最低，粒度适中这个地步，即使一期项目会适当延期，但是当二期或者新的后续需求到来时，应用当前已知的这个框架仍然能够很好的适应新的系统，我们只需要在原有系统上适当调整改进即可，这样最终的结果，肯定比第一种工作方式不仅省去很多劳动力和时间，也使很多技术难点大大降低。最直接的场景就是，我们不需要搞封闭式开发和疯狂加班！这一直是我最为诟病的国内开发方法。
毫无疑问，第一种开发方式最好的结果，也是二期项目推倒重来，然后做到一个尽量的可伸缩性的，和第二种开发方式比较接近的新的构架和模式来完成任务，由于时间，人力，资源等诸多方面因素的限制，很难做到第二种开发方式描述的软件产品的程度。那么等于一个任务迭代了2次，第一次完全是一个半成品，敷衍客户而已，第二次的产品则勉强及格。或者换句话说，架构师，项目经理的眼光没有那么长远，还达不到一个任务一次就漂亮的完成的境界；而第二种开发方式，显然从一开始就以精品购物指南的心态去完成一个任务，各方各面都经过了仔细的推敲和测试，完成任务时自然是一个精品，软件的高可复用性，可伸缩性自然保证了项目可以不断持续延伸，同时毫无疑问彰显了架构师和项目经理深厚的行业背景经验和多年从业能力。
而国内软件行业的现状是什么呢？我想不用细说也可知。从这里可以看出国内软件人的浮躁心态和从业人员水平相对低下的现状，不仅是企业本身，项目管理者也根本没有耐心去真正踏踏实实去做一个项目，仅仅是项目需求到来之后，不加思考的用一个仅仅是当前适用的模式去完成它，而对于项目的后续发展，完全置若罔闻，这恐怕是国内架构师和项目经理最常见的思路。
可以看出，我们当前大部分的软件水平还仅仅停留在增删查改(CRUD)的水平上，而真正IT技术发达的国家已经意识到了如何更进一步的加速软件行业发展，那才是软件行业的核心竞争力，所以他们放心的把CRUD外包给我们，而我们自己的惰性也一再彰显，仅仅停留在CRUD的程度就已经满足知足，要知道这是远远不够的，只有在软硬件行业中掌握尖端，最前沿的核心技术，才可以步入信息化强国的行列，千万别以为会几个简单的增删查改就掌握了技术的全部，如果这样，软件外包的麻痹作用就达到了，美帝，日本等软件强国此时则在一旁偷笑。因此，请同行们戒骄戒躁，利用当前的外包契机，努力快速提高自身科技水平，大力钻研和创新出核心技术才是发展软件行业的上策。如何稳步提升我们的软件产品水平，是一个任重而道远的话题，但是相信从我做起，这一天的到来必然会越来越快。
最后，建议大家去读一下李开复的《世界因你不同》，在此书里我们沿着开复的职场轨迹，明显可以看到硅谷外企在核心IT技术，最前沿技术研发上的大力投入和持之以恒的耐心，因为只有这样，才能保证企业乃至国家的科技的核心竞争力。再回头想想，国内的大小软件作坊们，整天只是在自己涉足的行业/领域内摸爬滚打，搞搞简单的CURD，和国外信息技术列强有天壤之别的差距，可是还自认为掌握了IT核心竞争力，沾沾自喜，甚至立功筑碑。

评论

50 楼 potian 2010-03-27  

没有必要再讨论了吧

49 楼 gigix 2010-03-27  

sharong 写道

首先请你不要人身攻击，把你那两个脏字赶紧删除，别在这里充老大，还轮不到你。
另外，正面回答你，你说的这仅仅是xp要求的迭代，你看了我之前的论述么？你以为其他开发模式中没有迭代这个说法么？你认为所有的开发模式下的迭代含义和强调的完全一样么？到底谁是井底之蛙？

自己去wikipedia搜索iterative development
懒得说了。

48 楼 sharong 2010-03-27  

gigix 写道

sharong 写道

gigix 写道

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

你发布了几次？

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

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

这种话我听了就只想说两个字
我呸
发布是不是迭代的根本要点？是不是必须达到可发布状态才算真正的迭代？“迭代的实质”这种东西不是你自己空口说白话就能定了的。

wikipedia 写道

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system.

看清楚没有？什么叫“可交付的”懂不懂？你做那些“迭代”，每个迭代末的东西敢不敢拿给客户去用？

（最烦有些人，不知道哪里来的自信，开口就总以为自己掌握的全是实质全是真理。井底之蛙。）

首先请你不要人身攻击，把你那两个脏字赶紧删除，别在这里充老大，还轮不到你。
另外，正面回答你，你说的这仅仅是xp要求的迭代，你看了我之前的论述么？你以为其他开发模式中没有迭代这个说法么？你认为所有的开发模式下的迭代含义和强调的完全一样么？
另外，我文中没有提发布之类的说法，你就臆断的认为我不知道发布么？就像我每天吃几次饭，我没有在文中提及，你认为我是超人，不用吃饭么？到底谁是井底之蛙？
我更烦你这种人，我把文章发到论坛就是希望和大家认真讨论，没有认为自己掌握了什么真理，更不是想听到什么污言秽语，你作为一个技术人员，不为自己的行为羞耻么？
你作为一个这样不文明的人，怎么就在javaeye混了这么久？你还让别人怎么看你？你也配javaeye给你那个资深的称号？

47 楼 gigix 2010-03-27  

sharong 写道

gigix 写道

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

你发布了几次？

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

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

这种话我听了就只想说两个字
我呸
发布是不是迭代的根本要点？是不是必须达到可发布状态才算真正的迭代？“迭代的实质”这种东西不是你自己空口说白话就能定了的。

wikipedia 写道

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system.

看清楚没有？什么叫“可交付的”懂不懂？你做那些“迭代”，每个迭代末的东西敢不敢拿给客户去用？

（最烦有些人，不知道哪里来的自信，开口就总以为自己掌握的全是实质全是真理。井底之蛙。）

46 楼 clamp 2010-03-26  

面向客户的迭代的周期长短一般取决于团队对需求的控制力以及概要设计能力

周期的长短和需求控制力的强弱成正比，和概要设计能力的强弱成正比


如果是内部集成的迭代周期，取决于团队的测试能力

测试能力越强（例如可以做到完全自动化测试），集成周期越短（例如持续集成）

45 楼 asd 2010-03-26  

工作激情,我有个同事说得好:钱给得多就有激情,其它啥都白扯.

44 楼 asd 2010-03-26  

一个项目,商务上报价几百w,反应到开发这边就是那么几个人月.随便你敏捷还是瀑布,随便你发布多少版本,反正需要几个月后项目一定顺利验收结款,否则公司就要亏本,你这个开发负责人就得挨批或者滚蛋,自己看着办.

43 楼 asd 2010-03-26  

tuti 写道

tuti 写道

sharong 写道

我很负责的说我想说明的不是瀑布法，而是尽量减少迭代次数

请教一下，为什么要说“尽量”减少？为什么不直接说就1个迭代，那样不就“最尽量”了吗？

那“尽量”是不是表示有些情况下，一个迭代不行的？

那么在那些情况下应该是多个迭代呢？

楼主你推荐确定迭代时间长度的规则又是什么呢？

如果这些问题太教条了，那么先抱歉一下。只是实际工作如果只有“思路”而没些“教条”，我就不知道该怎么办了。

请楼主回一下这几个问题，谢谢。

以前在论坛上遇到一个朋友的实际案例:

引用

他们公司给日本第一大证券交易商(不知道名字,简称 A公司吧)开发了一个系统,计划开发周期三年,做了一年半,客户反映也不错,这时候,日本第三大证券交易商( C公司)的一个类似的系统也已经上线了,同样是该公司做的.于是乎,这之后不久,A公司提出了一大堆新的需求,基本上都是参照C公司的系统,比如C公司系统的某个参数是响应时间10s,A公司要求给他们公司的新系统的响应时间缩短到1s,诸如此类.

那哥们说当时他都崩溃了,因为C公司的系统几乎已经是技术的极限了!
后来这个问题怎么处理了就不知道了.

实际项目中,排除能力问题,导致需求变更的这样的例子比比皆是,显然也不能"控制"这样的需求,除非你这个公司想要倒闭了.
抛开实际的项目环境谈开发,搞笑呢?一个周期一个月和一个周期两三年的项目开发计划能一样么?给一个普通民企开发系统和给中国政府开发系统能一样么?做外包和做产品能一样么?
你可以自己定义一个一周的提交周期,可人家局长处长总经理根本就没有时间搭理你,人家半年多忽然心血来潮想看看你的系统然后提出一堆让你骂娘的需求你还得千恩万谢的感谢领导的关怀--不然你的项目就别做了.所有的方法论里面忽略了一条:客户那个真正的利益相关人是不可能真正加入你的项目组的,因为这些人一般都很忙.

42 楼 daquan198163 2010-03-26  

sharong 写道

我这篇文章的内在意思不是讨论迭代开发，也不是讨论你们眼里的瀑布式开发模式，更不是比较几种开发模式之间孰优孰劣。
我的看法是，我们不排斥迭代，但是要尽量减少迭代开发次数，不要使自己陷入无休止的迭代开发中让工作热情消失殆尽。这真实体现了项目经理和架构师的行业经验和技术功力，因为大量事实告诉我们，无休止的迭代开发过程，会使开发组成员疲于奔命，同时开发热情急剧下降，造成软件质量不升反降。同时由于开发人员工作热情急剧下降，软件质量下降而造成项目最终失败。除非你一次迭代周期长似1年左右，那样又和xp的精神不符，按我看仍然可以认为是迭代开发，按lss的，就不知道怎么描述好了。
如果谁对上面这些无休止迭代开发所产生出来的恶果没有深切体会，只能说开发经验实在太少，经历的项目太少，也可能没有在项目中负责过核心代码的开发。太多的人太信仰权威了，我记得以前有人质疑过xp开发中的大量testing的编写，那么我就是在质疑无休止迭代开发的恶果。要充分利用自己的经验和水平，尽量减少迭代次数。

更短的迭代意味着有更多的机会通过交付产品、演示成果来振奋士气、获取用户的反馈，
就好比游泳，一口气游的太远不换气肯定不舒服，多出来换换气可以有的更久更快。

当然这一切的前提是软件质量，如果质量不达到一定的水平，短迭代就会显得比长迭代更痛苦，
因为迭代一次被客户骂一次，“技术债”越欠越多代码越改越烂……
但是这仍然比长迭代好，因为问题得以尽早暴露。

41 楼 tuti 2010-03-26  

tuti 写道

sharong 写道

我很负责的说我想说明的不是瀑布法，而是尽量减少迭代次数

请教一下，为什么要说“尽量”减少？为什么不直接说就1个迭代，那样不就“最尽量”了吗？

那“尽量”是不是表示有些情况下，一个迭代不行的？

那么在那些情况下应该是多个迭代呢？

楼主你推荐确定迭代时间长度的规则又是什么呢？

如果这些问题太教条了，那么先抱歉一下。只是实际工作如果只有“思路”而没些“教条”，我就不知道该怎么办了。

请楼主回一下这几个问题，谢谢。

40 楼 抛出异常的爱 2010-03-26  

sharong 写道

lkj107 写道

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

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

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

从来没管理过周期性上年的项目。。。。（除非维护）
也从来没管理过需求大于30/人月(最长的项目6个月那在设计时预计是二个月时间)
想像不出来长达一年的项目是怎么样的
产品要作成什么样才需要项目经理在项目中期来增加需求
那样子不打击士气才怪呢。
另：你让他们加班了吧

sharong 写道

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

需求文档要还是要写的。它们在bug zilla上面
我的项目中的设计文档是用照片组成的。管理的。贴在wiki上面
设计时间一般会比写代码时间长
另：我是想问一下cmm5文档有哪家不是后补的
先写的那些文档到最后还能用的上的有百分之几？

39 楼 sharong 2010-03-26  

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

38 楼 sharong 2010-03-26  

gigix 写道

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

你发布了几次？

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

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

37 楼 gigix 2010-03-25  

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

你发布了几次？

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

36 楼 sharong 2010-03-25  

asd 写道

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

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

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

35 楼 sharong 2010-03-25  

lkj107 写道

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

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

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

34 楼 asd 2010-03-25  

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

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

33 楼 lkj107 2010-03-25  

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

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

32 楼 抛出异常的爱 2010-03-25  

sharong 写道

tuti 写道

potian 写道

我理解楼主的意思是这样的
1. 几乎所有的项目需求是要变的
2. 所以不应该迭代，主要应该靠开始的设计和评估来应对以后可能的变化

如果这楼主不知道XP，只知道瀑布，有这种想法很好理解。
但楼主说知道XP，而且有XP的实际经验，那他还有这种想法我就无法理解了。
而且举得例子也很奇怪“连续迭代开发3次以上，他们的开发激情，热情将全部丧失殆尽”。
我只见过做一些长期项目，搞得开发人员热情丧尽，从来没见过短迭代能把热情丧尽的。

所以我想请楼主说明一下，他所说的XP实践，到底是做了些什么。

我觉得奇怪的是我，我的经验正是短期迭代，把热情丧失殆尽的，到第四次迭代的时候，已经完全头晕脑胀，不想继续下去了。
举个例子，开发一个在线人数统计系统，最初的设想用servlet即可实现，开发也相当迅速，一天左右；接着项目经理过来说，我们可能要承受至少十万级访问量，还得重新设计并迭代之，这个时候，我们考虑就可以直接用memched这种分布式缓存来实现，开发起来也不是很慢大概4，5天吧；接着项目经理又提出了新的需求，也许网站要承受百万级访问量，同时web和wap端要尽量同步，这个时候在线人数统计系统显然还得重新迭代，不好意思，对我来说，这基本就已经是迭代的极限了，在第3次迭代的时候由于要尽量同步，分布式系统之类的，已经比较头晕脑胀了，4，5天好不容易完成；结果项目经理又过来说，为了今后的拓展和兼容，最好能考虑承受亿计海量访问，显然你还得重新考虑代码，进行大量的调整，当时我们研究的结果，亿级访问量，对memched的操作和其他方式的有相当大的变动，很多代码需要调整。如果哪位觉得这样的迭代开发越来越有激情，越来越喜欢。
请您仔细和我说说这样开发程序的乐趣表现在哪些方面，也好让我长长见识。
或者您觉得这根本不是迭代开发，也请仔细说明之。
根据上面的论述，我想potian不会认为我说的迭代是重做吧？
另外，前面的问题回答一下，我的说法是应该尽量减少迭代次数，正像上面说的，现代软件有不迭代的开发么？

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

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

31 楼 wandou 2010-03-25  

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