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

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

评论

30 楼 iaimstar 2010-03-23  

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

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

29 楼 sg552 2010-03-23  

说实话一看到某些 “支持百万访问量” 的需求我就蛋疼。。。。

各位的回帖很精彩。

28 楼 tuti 2010-03-23  

sharong 写道

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

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

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

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

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

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

27 楼 sharong 2010-03-23  

就因为我在文章开头漏写了几个字，几位就顽固的认为我在吹捧瀑布开发模式，那现在做以下修改：

抛开软件的开发过程及那些瀑布开发模式，原型开发模式，xp开发模式等等不谈。

这篇文章不是谈开发模式，是谈思路，可以了么？

26 楼 sharong 2010-03-23  

tuti 写道

楼主你说不就是瀑布模型吗？ 大家沿着一条大路，一路高歌猛进，直达目的地。

“瀑布模型”作为一个美好愿望，以及对外行人的忽悠得以长存。
而现实项目中“瀑布模型”已经被粉碎了无数遍。

为什么“瀑布模型”会失败？就是因为大家的脑子对于复杂的现实而言，非常得不好使。如果你们有足够智慧的脑子与无比顺畅的沟通，那么你们就去“瀑布”好了。
如果你们不具备这些条件而要去搞，那就是刻舟求剑。

在我所经历的项目中，3次以上的迭代增量开发都是很平常的。当团队与客户在看到每次增量的结果而感到赞许，进而激发出新的好点子时，怎么会感到没热情呢？

为什么会问你很多细节，那就是因为迭代开发都有严格规则和套路的，并不是随意变化需求就叫做迭代开发。你们为什么会做得如此倦怠，那是因为你们做的根本就不是“迭代开发”。

所以说，一个业内人士去鼓吹“瀑布”，不是有其特殊的目的，就是有待提高。

根据你最后两段的论述，可以看出是一个十足的教条主义，所以你会顽固的认为我的文章是在鼓吹瀑布开发模式。

25 楼 sharong 2010-03-23  

potian 写道

sharong 写道

tuti 写道

sharong 写道

   另外，我们使用scrum管理项目的优先级及开发进度和sprint。

楼主再麻烦说明一下：
你们搞Scrum之前有project manager吗？如果有，搞了Scrum之后，Project Manager干什么去了。

你们的Scrum Master受过培训吗？

你们是日常都是怎么搞Scrum的？


谢谢

我们不需要纠缠在scrum上面，我只是想说明做项目能够不分优先，孰轻孰重么？
另外，我文章的意思您看懂了么？我强调的是要尽量减少迭代开发的次数，以节约人力物力和时间等成本，和迭代开发本身并无任何冲突。
如果您连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。
另外，从你们反驳的字里行间怎么看出，和文章所指出的立场基本一致？这也叫反驳么？还是众位没有仔细阅读本文？

你举了一个例子，然后我告诉你这个例子的问题，你说这不是实际开发，然后接着说连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。

我已经告诉你那个不是迭代

我下面的话非常可能是错的，但是我只能很遗憾地告诉你，我的心里是这么认为的：
1. 不是众位没有仔细阅读你的本文而是你根本就没看到我们再说什么
2. 我和tuti的看法基本一样，你的方法是要瀑布法。而且据我观察，你们现在可能什么法也没用--这并不是什么坏事，不一定要什么法才能干事情的，有句话说得好，一百个项目一百个法，虽然指的不是你们这种情况。但不能根据你们的现状去推测毫无关系的XP或者UP的优劣、缺陷。

我很负责的说我想说明的不是瀑布法，而是尽量减少迭代次数，因为我在项目中大量使用的也非瀑布开发模式。
另外，瀑布法开发模式里也要求进行多次迭代，再说一遍，迭代并不是随着xp的产生才出现的，迭代是一个很古老的计算机术语了。

24 楼 potian 2010-03-23  

sharong 写道

tuti 写道

sharong 写道

   另外，我们使用scrum管理项目的优先级及开发进度和sprint。

楼主再麻烦说明一下：
你们搞Scrum之前有project manager吗？如果有，搞了Scrum之后，Project Manager干什么去了。

你们的Scrum Master受过培训吗？

你们是日常都是怎么搞Scrum的？


谢谢

我们不需要纠缠在scrum上面，我只是想说明做项目能够不分优先，孰轻孰重么？
另外，我文章的意思您看懂了么？我强调的是要尽量减少迭代开发的次数，以节约人力物力和时间等成本，和迭代开发本身并无任何冲突。
如果您连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。
另外，从你们反驳的字里行间怎么看出，和文章所指出的立场基本一致？这也叫反驳么？还是众位没有仔细阅读本文？

你举了一个例子，然后我告诉你这个例子的问题，你说这不是实际开发，然后接着说连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。

我已经告诉你那个不是迭代

我下面的话非常可能是错的，但是我只能很遗憾地告诉你，我的心里是这么认为的：
1. 不是众位没有仔细阅读你的本文而是你根本就没看到我们再说什么
2. 我和tuti的看法基本一样，你的方法是要瀑布法。而且据我观察，你们现在可能什么法也没用--这并不是什么坏事，不一定要什么法才能干事情的，有句话说得好，一百个项目一百个法，虽然指的不是你们这种情况。但不能根据你们的现状去推测毫无关系的XP或者UP的优劣、缺陷。

23 楼 tuti 2010-03-23  

楼主你说不就是瀑布模型吗？ 大家沿着一条大路，一路高歌猛进，直达目的地。

“瀑布模型”作为一个美好愿望，以及对外行人的忽悠得以长存。
而现实项目中“瀑布模型”已经被粉碎了无数遍。

为什么“瀑布模型”会失败？就是因为大家的脑子对于复杂的现实而言，非常得不好使。如果你们有足够智慧的脑子与无比顺畅的沟通，那么你们就去“瀑布”好了。
如果你们不具备这些条件而要去搞，那就是刻舟求剑。

在我所经历的项目中，3次以上的迭代增量开发都是很平常的。当团队与客户在看到每次增量的结果而感到赞许，进而激发出新的好点子时，怎么会感到没热情呢？

为什么会问你很多细节，那就是因为迭代开发都有严格规则和套路的，并不是随意变化需求就叫做迭代开发。你们为什么会做得如此倦怠，那是因为你们做的根本就不是“迭代开发”。

所以说，一个业内人士去鼓吹“瀑布”，不是有其特殊的目的，就是有待提高。

22 楼 sharong 2010-03-23  

tuti 写道

sharong 写道

   另外，我们使用scrum管理项目的优先级及开发进度和sprint。

楼主再麻烦说明一下：
你们搞Scrum之前有project manager吗？如果有，搞了Scrum之后，Project Manager干什么去了。

你们的Scrum Master受过培训吗？

你们是日常都是怎么搞Scrum的？


谢谢

我们不需要纠缠在scrum上面，我只是想说明做项目能够不分优先，孰轻孰重么？
另外，我文章的意思您看懂了么？我强调的是要尽量减少迭代开发的次数，以节约人力物力和时间等成本，和迭代开发本身并无任何冲突。
如果您连续迭代开发3次以上仍然是乐此不疲，我也希望您举个实例来说明一下。
另外，从你们反驳的字里行间怎么看出，和文章所指出的立场基本一致？这也叫反驳么？还是众位没有仔细阅读本文？

21 楼 tuti 2010-03-23  

sharong 写道

   另外，我们使用scrum管理项目的优先级及开发进度和sprint。

楼主再麻烦说明一下：
你们搞Scrum之前有project manager吗？如果有，搞了Scrum之后，Project Manager干什么去了。

你们的Scrum Master受过培训吗？

你们是日常都是怎么搞Scrum的？


谢谢

20 楼 gigix 2010-03-23  

tuti 写道

所以每次有人说自己玩XP不爽的时候，就要请他说一下他们具体是怎么玩的。
基本都是“自己乱来”。

每天都有人跟我说，敏捷了嘛，敏捷叫我们不要写文档嘛，所以我们不写文档嘛，所以沟通成问题了嘛，都是敏捷闹的嘛
对这种话的标准回答是
敏捷还叫你先写测试再写代码呢，你写测试了没？
别跟我说敏捷叫你如何如何。敏捷叫你做的事你也没做。你只是在找借口偷懒而已。

19 楼 sharong 2010-03-23  

potian 写道

sharong 写道

tuti 写道

potian 写道

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

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

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

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

首先赞一下你们的项目经理

然后我要首先问一下你们的用户需求是怎么样的，譬如说你们的网站定位是怎么样的，难道一开始定位成公司内部网站，后来变成全世界最大的网站了。

如果网站定位的问题都没有解决，有一种方法可以解决这个问题，我们设计一个全世界最大的包括世界上所有网站可能出现的所有功能的网站，那就一切都OK了。

所以XP有一个隐喻或者体系结构的概念。这是用户、销售、开发人员、决策者对整个软件的一个总体看法和观点。一言可以蔽之则最佳。

另外，你们项目经理都是可能。。。可能。。。，这是典型的需要用迭代来解决的问题，让他告诉你到底是怎么一个网站，例如在1年内网站到底会达到什么样的容量，然后按照他目前确实需要的能力（或稍强一点）去实现，如果在1年后真的出现了你们目前无法解决的问题，迭代之。

你们这个项目我感觉连基本的用户交流都没有，就算项目经理充当用户，也需要和你们研发讨论一下项目的对象、范围、目的。而用户交流是XP最最看重的问题。

针对这个功能，他可以提出1百万、1千万、1亿、10亿、100亿、1万亿的要求，你们可以了解哪些是必须的，哪些只是他脑袋的设想。如果他坚持要100亿，你们可以告诉他实现的成本。这是一个功能被描述成story被分解成task之前最最基本的事情。

反过来，这是一个需求的问题，和设计没有什么关系，不管你怎么设计，如果你一开始针对1百万做了设计，最后他变成1万亿，你的设计怎么解决他的问题，除非你设计一个世界极限的解决方案，不然你都要防着他有更高的要求。

我只是举个例子，并不需要看成是一个真正的项目，只是拿这个例子来表现需求的不断变更，这难道和淘宝所经历的不相似么？
你所说的最后一段话，正是我的文章想要表达的意思一部分，一个方面。
另外，我们使用scrum管理项目的优先级及开发进度和sprint。

18 楼 daquan198163 2010-03-22  

我猜楼主的项目“技术债”欠的太多了，导致多次迭代以后利息都付不起了，所以做不下去。
事实上大多数项目都存在这个问题，只是有的人预计到自己要破产了，根本就不会继续迭代做下去，做一锤子买卖挣到钱了就撤。

17 楼 RCFans 2010-03-22  

选择迭代开发方法比较重要的前提就是标出任务优先级，你们的项目失败在没有掌握项目管理最基本的原理，和用什么方法无关。

16 楼 RCFans 2010-03-22  

sharong 写道

wandou 写道

一句话，核心竞争力就是人。如何招人，招什么人，如何用人，如何评估人的价值，如何留住人。
关键在于如何评估人的价值。这点做好了，其他就有了。

楼上的理解和我不一样，看了《世界因你不同》之后，可以明显发现，高精尖技术，例如语音识别，人工智能，cpu芯片技术等等，全都被美帝等科技强国把持着，而且国家立法规定有专利保护等等，不准泄密。
而我们所谓的计算机技术，99%都是所谓的CRUD，甚至神州数码这种国人值得骄傲的上市公司，也仅仅是千篇一律的什么税务的，金融的，物流的CRUD，这就是国家推崇的企业信息化。根本没有掌握科技世界核心的高精尖技术。
当然，应该认识到，要想有朝一日掌握和发展自己的核心技术，先做好基本的CRUD是必须的。

CRUD是基建，路都没修通有什么商业帝国，高精尖是帝国上层建筑，跟我们努不努力没有任何关系。

15 楼 tuti 2010-03-22  

所以每次有人说自己玩XP不爽的时候，就要请他说一下他们具体是怎么玩的。
基本都是“自己乱来”。

14 楼 potian 2010-03-22  

sharong 写道

tuti 写道

potian 写道

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

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

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

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

首先赞一下你们的项目经理

然后我要首先问一下你们的用户需求是怎么样的，譬如说你们的网站定位是怎么样的，难道一开始定位成公司内部网站，后来变成全世界最大的网站了。

如果网站定位的问题都没有解决，有一种方法可以解决这个问题，我们设计一个全世界最大的包括世界上所有网站可能出现的所有功能的网站，那就一切都OK了。

所以XP有一个隐喻或者体系结构的概念。这是用户、销售、开发人员、决策者对整个软件的一个总体看法和观点。一言可以蔽之则最佳。

另外，你们项目经理都是可能。。。可能。。。，这是典型的需要用迭代来解决的问题，让他告诉你到底是怎么一个网站，例如在1年内网站到底会达到什么样的容量，然后按照他目前确实需要的能力（或稍强一点）去实现，如果在1年后真的出现了你们目前无法解决的问题，迭代之。

你们这个项目我感觉连基本的用户交流都没有，就算项目经理充当用户，也需要和你们研发讨论一下项目的对象、范围、目的。而用户交流是XP最最看重的问题。

针对这个功能，他可以提出1百万、1千万、1亿、10亿、100亿、1万亿的要求，你们可以了解哪些是必须的，哪些只是他脑袋的设想。如果他坚持要100亿，你们可以告诉他实现的成本。这是一个功能被描述成story被分解成task之前最最基本的事情。

反过来，这是一个需求的问题，和设计没有什么关系，不管你怎么设计，如果你一开始针对1百万做了设计，最后他变成1万亿，你的设计怎么解决他的问题，除非你设计一个世界极限的解决方案，不然你都要防着他有更高的要求。

13 楼 sharong 2010-03-22  

tuti 写道

potian 写道

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

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

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

纠正你的一个看法，瀑布开发模式和RUP也是要求不断迭代的。迭代这个提法是很早期的软件开发模式。并不是由于xp才有的迭代。

12 楼 sharong 2010-03-22  

tuti 写道

potian 写道

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

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

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

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

11 楼 potian 2010-03-22  

tuti 写道

potian 写道

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

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

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

1.应该说任何现代的开发方法都是迭代的，这和XP无关
2.我理解楼主的迭代可能就是重做的意思，因为一般来说迭代的阶段性的可以在较短时间内实现的目标是不断鼓励开发热情最好的手段之一，相反一个短时间无法达到的目标才可能让人筋疲力尽
3.从楼主的话

sharong 写道

延续性，尽量减少无止境的迭代开发，只能在质量，时间，兴趣，激情等等诸多因素中实现双赢。

无法理解为什么要去修改一个已经可以运行的程序，为什么要迭代，说到底只有一个驱动力：“用户需求的变化”，所以无止境的的想法到底来自何处，也需要楼主说明