锁定老帖子 主题:软件开发周期和IT核心竞争力的个人见解
精华帖 (0) :: 良好帖 (22) :: 灌水帖 (0) :: 隐藏帖 (31)
|
|
---|---|
作者 | 正文 |
发表时间:2010-03-22
potian 写道 我理解楼主的意思是这样的
1. 几乎所有的项目需求是要变的 2. 所以不应该迭代,主要应该靠开始的设计和评估来应对以后可能的变化 如果这楼主不知道XP,只知道瀑布,有这种想法很好理解。 但楼主说知道XP,而且有XP的实际经验,那他还有这种想法我就无法理解了。 而且举得例子也很奇怪“连续迭代开发3次以上,他们的开发激情,热情将全部丧失殆尽”。 我只见过做一些长期项目,搞得开发人员热情丧尽,从来没见过短迭代能把热情丧尽的。 所以我想请楼主说明一下,他所说的XP实践,到底是做了些什么。 |
|
返回顶楼 | |
发表时间:2010-03-22
最后修改:2010-03-22
tuti 写道 potian 写道 我理解楼主的意思是这样的
1. 几乎所有的项目需求是要变的 2. 所以不应该迭代,主要应该靠开始的设计和评估来应对以后可能的变化 如果这楼主不知道XP,只知道瀑布,有这种想法很好理解。 但楼主说知道XP,而且有XP的实际经验,那他还有这种想法我就无法理解了。 而且举得例子也很奇怪“连续迭代开发3次以上,他们的开发激情,热情将全部丧失殆尽”。 我只见过做一些长期项目,搞得开发人员热情丧尽,从来没见过短迭代能把热情丧尽的。 所以我想请楼主说明一下,他所说的XP实践,到底是做了些什么。 1.应该说任何现代的开发方法都是迭代的,这和XP无关 2.我理解楼主的迭代可能就是重做的意思,因为一般来说迭代的阶段性的可以在较短时间内实现的目标是不断鼓励开发热情最好的手段之一,相反一个短时间无法达到的目标才可能让人筋疲力尽 3.从楼主的话 sharong 写道 延续性,尽量减少无止境的迭代开发,只能在质量,时间,兴趣,激情等等诸多因素中实现双赢。
无法理解为什么要去修改一个已经可以运行的程序,为什么要迭代,说到底只有一个驱动力:“用户需求的变化”,所以无止境的的想法到底来自何处,也需要楼主说明 |
|
返回顶楼 | |
发表时间:2010-03-22
最后修改:2010-03-22
tuti 写道 potian 写道 我理解楼主的意思是这样的
1. 几乎所有的项目需求是要变的 2. 所以不应该迭代,主要应该靠开始的设计和评估来应对以后可能的变化 如果这楼主不知道XP,只知道瀑布,有这种想法很好理解。 但楼主说知道XP,而且有XP的实际经验,那他还有这种想法我就无法理解了。 而且举得例子也很奇怪“连续迭代开发3次以上,他们的开发激情,热情将全部丧失殆尽”。 我只见过做一些长期项目,搞得开发人员热情丧尽,从来没见过短迭代能把热情丧尽的。 所以我想请楼主说明一下,他所说的XP实践,到底是做了些什么。 我觉得奇怪的是我,我的经验正是短期迭代,把热情丧失殆尽的,到第四次迭代的时候,已经完全头晕脑胀,不想继续下去了。 举个例子,开发一个在线人数统计系统,最初的设想用servlet即可实现,开发也相当迅速,一天左右;接着项目经理过来说,我们可能要承受至少十万级访问量,还得重新设计并迭代之,这个时候,我们考虑就可以直接用memched这种分布式缓存来实现,开发起来也不是很慢大概4,5天吧;接着项目经理又提出了新的需求,也许网站要承受百万级访问量,同时web和wap端要尽量同步,这个时候在线人数统计系统显然还得重新迭代,不好意思,对我来说,这基本就已经是迭代的极限了,在第3次迭代的时候由于要尽量同步,分布式系统之类的,已经比较头晕脑胀了,4,5天好不容易完成;结果项目经理又过来说,为了今后的拓展和兼容,最好能考虑承受亿计海量访问,显然你还得重新考虑代码,进行大量的调整,当时我们研究的结果,亿级访问量,对memched的操作和其他方式的有相当大的变动,很多代码需要调整。如果哪位觉得这样的迭代开发越来越有激情,越来越喜欢。 请您仔细和我说说这样开发程序的乐趣表现在哪些方面,也好让我长长见识。 或者您觉得这根本不是迭代开发,也请仔细说明之。 根据上面的论述,我想potian不会认为我说的迭代是重做吧? 另外,前面的问题回答一下,我的说法是应该尽量减少迭代次数,正像上面说的,现代软件有不迭代的开发么? |
|
返回顶楼 | |
发表时间:2010-03-22
tuti 写道 potian 写道 我理解楼主的意思是这样的
1. 几乎所有的项目需求是要变的 2. 所以不应该迭代,主要应该靠开始的设计和评估来应对以后可能的变化 如果这楼主不知道XP,只知道瀑布,有这种想法很好理解。 但楼主说知道XP,而且有XP的实际经验,那他还有这种想法我就无法理解了。 而且举得例子也很奇怪“连续迭代开发3次以上,他们的开发激情,热情将全部丧失殆尽”。 我只见过做一些长期项目,搞得开发人员热情丧尽,从来没见过短迭代能把热情丧尽的。 所以我想请楼主说明一下,他所说的XP实践,到底是做了些什么。 纠正你的一个看法,瀑布开发模式和RUP也是要求不断迭代的。迭代这个提法是很早期的软件开发模式。并不是由于xp才有的迭代。 |
|
返回顶楼 | |
发表时间:2010-03-22
最后修改: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万亿,你的设计怎么解决他的问题,除非你设计一个世界极限的解决方案,不然你都要防着他有更高的要求。 |
|
返回顶楼 | |
发表时间:2010-03-22
最后修改:2010-03-22
所以每次有人说自己玩XP不爽的时候,就要请他说一下他们具体是怎么玩的。
基本都是“自己乱来”。 |
|
返回顶楼 | |
发表时间:2010-03-22
sharong 写道 wandou 写道 一句话,核心竞争力就是人。如何招人,招什么人,如何用人,如何评估人的价值,如何留住人。
关键在于如何评估人的价值。这点做好了,其他就有了。 楼上的理解和我不一样,看了《世界因你不同》之后,可以明显发现,高精尖技术,例如语音识别,人工智能,cpu芯片技术等等,全都被美帝等科技强国把持着,而且国家立法规定有专利保护等等,不准泄密。 而我们所谓的计算机技术,99%都是所谓的CRUD,甚至神州数码这种国人值得骄傲的上市公司,也仅仅是千篇一律的什么税务的,金融的,物流的CRUD,这就是国家推崇的企业信息化。根本没有掌握科技世界核心的高精尖技术。 当然,应该认识到,要想有朝一日掌握和发展自己的核心技术,先做好基本的CRUD是必须的。 CRUD是基建,路都没修通有什么商业帝国,高精尖是帝国上层建筑,跟我们努不努力没有任何关系。 |
|
返回顶楼 | |
发表时间:2010-03-22
最后修改:2010-03-22
选择迭代开发方法比较重要的前提就是标出任务优先级,你们的项目失败在没有掌握项目管理最基本的原理,和用什么方法无关。
|
|
返回顶楼 | |
发表时间:2010-03-22
最后修改:2010-03-22
我猜楼主的项目“技术债”欠的太多了,导致多次迭代以后利息都付不起了,所以做不下去。
事实上大多数项目都存在这个问题,只是有的人预计到自己要破产了,根本就不会继续迭代做下去,做一锤子买卖挣到钱了就撤。 |
|
返回顶楼 | |
发表时间:2010-03-23
最后修改: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。 |
|
返回顶楼 | |