|
锁定老帖子 主题：软件开发周期和IT核心竞争力的个人见解
精华帖 (0) :: 良好帖 (22) :: 灌水帖 (0) :: 隐藏帖 (31)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-26
最后修改：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文档有哪家不是后补的 先写的那些文档到最后还能用的上的有百分之几？ |
| 返回顶楼 | |
|
发表时间：2010-03-26
tuti 写道 sharong 写道 我很负责的说我想说明的不是瀑布法，而是尽量减少迭代次数
请教一下，为什么要说“尽量”减少？为什么不直接说就1个迭代，那样不就“最尽量”了吗？ 那“尽量”是不是表示有些情况下，一个迭代不行的？ 那么在那些情况下应该是多个迭代呢？ 楼主你推荐确定迭代时间长度的规则又是什么呢？ 如果这些问题太教条了，那么先抱歉一下。只是实际工作如果只有“思路”而没些“教条”，我就不知道该怎么办了。 请楼主回一下这几个问题，谢谢。 |
| 返回顶楼 | |
|
发表时间：2010-03-26
最后修改：2010-03-26
sharong 写道 我这篇文章的内在意思不是讨论迭代开发，也不是讨论你们眼里的瀑布式开发模式，更不是比较几种开发模式之间孰优孰劣。
我的看法是，我们不排斥迭代，但是要尽量减少迭代开发次数，不要使自己陷入无休止的迭代开发中让工作热情消失殆尽。这真实体现了项目经理和架构师的行业经验和技术功力，因为大量事实告诉我们，无休止的迭代开发过程，会使开发组成员疲于奔命，同时开发热情急剧下降，造成软件质量不升反降。同时由于开发人员工作热情急剧下降，软件质量下降而造成项目最终失败。除非你一次迭代周期长似1年左右，那样又和xp的精神不符，按我看仍然可以认为是迭代开发，按lss的，就不知道怎么描述好了。 如果谁对上面这些无休止迭代开发所产生出来的恶果没有深切体会，只能说开发经验实在太少，经历的项目太少，也可能没有在项目中负责过核心代码的开发。太多的人太信仰权威了，我记得以前有人质疑过xp开发中的大量testing的编写，那么我就是在质疑无休止迭代开发的恶果。要充分利用自己的经验和水平，尽量减少迭代次数。 更短的迭代意味着有更多的机会通过交付产品、演示成果来振奋士气、获取用户的反馈， 就好比游泳，一口气游的太远不换气肯定不舒服，多出来换换气可以有的更久更快。 当然这一切的前提是软件质量，如果质量不达到一定的水平，短迭代就会显得比长迭代更痛苦， 因为迭代一次被客户骂一次，“技术债”越欠越多代码越改越烂…… 但是这仍然比长迭代好，因为问题得以尽早暴露。 |
| 返回顶楼 | |
|
发表时间：2010-03-26
tuti 写道 tuti 写道 sharong 写道 我很负责的说我想说明的不是瀑布法，而是尽量减少迭代次数
请教一下，为什么要说“尽量”减少？为什么不直接说就1个迭代，那样不就“最尽量”了吗？ 那“尽量”是不是表示有些情况下，一个迭代不行的？ 那么在那些情况下应该是多个迭代呢？ 楼主你推荐确定迭代时间长度的规则又是什么呢？ 如果这些问题太教条了，那么先抱歉一下。只是实际工作如果只有“思路”而没些“教条”，我就不知道该怎么办了。 请楼主回一下这几个问题，谢谢。 以前在论坛上遇到一个朋友的实际案例: 引用 他们公司给日本第一大证券交易商(不知道名字,简称 A公司吧)开发了一个系统,计划开发周期三年,做了一年半,客户反映也不错,这时候,日本第三大证券交易商( C公司)的一个类似的系统也已经上线了,同样是该公司做的.于是乎,这之后不久,A公司提出了一大堆新的需求,基本上都是参照C公司的系统,比如C公司系统的某个参数是响应时间10s,A公司要求给他们公司的新系统的响应时间缩短到1s,诸如此类.
那哥们说当时他都崩溃了,因为C公司的系统几乎已经是技术的极限了! 后来这个问题怎么处理了就不知道了. 实际项目中,排除能力问题,导致需求变更的这样的例子比比皆是,显然也不能"控制"这样的需求,除非你这个公司想要倒闭了. 抛开实际的项目环境谈开发,搞笑呢?一个周期一个月和一个周期两三年的项目开发计划能一样么?给一个普通民企开发系统和给中国政府开发系统能一样么?做外包和做产品能一样么? 你可以自己定义一个一周的提交周期,可人家局长处长总经理根本就没有时间搭理你,人家半年多忽然心血来潮想看看你的系统然后提出一堆让你骂娘的需求你还得千恩万谢的感谢领导的关怀--不然你的项目就别做了.所有的方法论里面忽略了一条:客户那个真正的利益相关人是不可能真正加入你的项目组的,因为这些人一般都很忙. |
| 返回顶楼 | |
|
发表时间：2010-03-26
最后修改：2010-03-26
一个项目,商务上报价几百w,反应到开发这边就是那么几个人月.随便你敏捷还是瀑布,随便你发布多少版本,反正需要几个月后项目一定顺利验收结款,否则公司就要亏本,你这个开发负责人就得挨批或者滚蛋,自己看着办.
|
| 返回顶楼 | |
|
发表时间：2010-03-26
工作激情,我有个同事说得好:钱给得多就有激情,其它啥都白扯.
|
| 返回顶楼 | |
|
发表时间：2010-03-26
面向客户的迭代的周期长短一般取决于团队对需求的控制力以及概要设计能力
周期的长短和需求控制力的强弱成正比，和概要设计能力的强弱成正比 如果是内部集成的迭代周期，取决于团队的测试能力 测试能力越强（例如可以做到完全自动化测试），集成周期越短（例如持续集成） |
| 返回顶楼 | |
|
发表时间：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.
看清楚没有？什么叫“可交付的”懂不懂？你做那些“迭代”，每个迭代末的东西敢不敢拿给客户去用？ （最烦有些人，不知道哪里来的自信，开口就总以为自己掌握的全是实质全是真理。井底之蛙。） |
| 返回顶楼 | |
|
发表时间：2010-03-27
最后修改：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给你那个资深的称号？ |
| 返回顶楼 | |
|
发表时间：2010-03-27
sharong 写道 首先请你不要人身攻击，把你那两个脏字赶紧删除，别在这里充老大，还轮不到你。
另外，正面回答你，你说的这仅仅是xp要求的迭代，你看了我之前的论述么？你以为其他开发模式中没有迭代这个说法么？你认为所有的开发模式下的迭代含义和强调的完全一样么？到底谁是井底之蛙？ 自己去wikipedia搜索iterative development 懒得说了。 |
| 返回顶楼 | |
