双倍赤裸裸的真理——评《软件工艺》

     这一点我非常赞成，不过迭代一般有两种理解，一种是功能递增式的迭代，这是一种粗粒度（当完成一种功能后不会再重新去重构），第二种就如你所说搬。
   的确，RUP在支持细粒度的迭代上的确不好（这也是它为什么看重里程碑的目的），并且它的阶段论缺乏了敏捷性，尤其在每一个阶段得不到保证的似乎，那么错误与失败的可能性就会累积，这个也是它相比XP和敏捷过程最大的缺陷。
  看来我们在迭代的概念上有些出入（我也许受经验主义的影响，认为迭代属于功能级的，需要向你多请教），同时在涉入的角度上也有些不同，也就产生了上番争论。

凤舞凰扬
你说的功能增量开发（这个词我想才是你应该的意思），是建立在对系统功能很好的划分粒度的基础上的，RUP在这个方向上依然是问题。
功能增量，或者说增量开发往往是和迭代伴生的，这也是迭代能进行更好的风险控制的基础。而RUP对于增量开发的支持不好，最大的原因还是在于其对于architecture的混乱定义。在《统一软件开发过程》P342是这样定义的：“对以下一系列重要问题的决策的总和：软件系统的组织；对组成系统的结构元素、接口以及这些元素在协作中的行为的选择；由这些结构与行为元素组合成更大的子系统的方式；用来指导将这些元素、接口、它们之间的协作以及组织起来的构架风格。软件构架不仅涉及到结构和行为，而且涉及使用（关系）、功能、性能、适应性、重用、可理解性、经济和技术约束及其权衡以及美学考虑等。”也就是说这个构架是包括了功能性等实际功能的，而不是一个纯粹抽象的、系统无关的规则性的结构。于是你就可以看到RUP中的框架中提到构架的5个视图的核心是用例视图，也就是说RUP中的设计思维重点是建立在系统功能而非系统概念和行业概念的基础上。当我们实施RUP的时候，所进行的最开始的工作也就是建立这个很实例化的architecture。我们需要把用户的需求进行风险和重要程度的划分，从中产生一个最小而包括系统主要核心功能的系统骨架，并且这个骨架是需要可以运行和可以测试的。这从表面看似乎和xp的这些纯粹敏捷方法的做法一致，其实其内涵差别巨大。在xp中只有一个抽象的隐喻负责解释这种结构性的约束，并且通过重构不断的强化这个约束。而其建立的最早核心只是面对一个迭代计划的，符合隐喻的一个实在程序，并不负责今后的所谓扩展和增强的责任。从这一点上说RUP对于构架的应用过于实际化，不够抽象，因而其系统的扩展必将受到其构架功能约束的约束。而xp则只是一个隐喻，更加抽象，对功能的增强只会扩展这个隐喻，或者加强这个隐喻，而不会受到这个隐喻的限制。也就是说在RUP下进行功能扩展有的时候是会成为不可能的。当然在这里我要说XP对于构架的支持只是比RUP好一些，他自身还没有达到一个真正以构架为核心进行开发的程度，但是他确实在这一点上比RUP强很多。
RUP的问题其实也就是UP的问题，其原因大多数属于其产生较早，所以显得粗糙而简陋。在国外之所以大公司很多都实施RUP或者实施过RUP，是由于国外大公司使用面向对象的开发方式比较早，在敏捷等等没有出现的情况下，使用CRM或者TSP这样明显不适合OO的方法进行开发是肯定不行的，因此他们就选择了唯一的OO开发方式。而最近敏捷成为一种主流的趋势发展这么快，就是因为很多组织都有过RUP或者其他UP的基础，从而转移到敏捷上非常的顺利。而从内核上说UP是一个支持敏捷的方法，而只是由于其产生的年代限制，其种种做法还不敏捷。所以最近2年来rational才会着重加强使RUP敏捷化的研究和实践。
其实说正统和主流，RUP现在已经成为一种二流货了，真正的正统现在是敏捷。所以现在问题也很悲哀，我们看看随便一本什么书，只要是最近出版的，就必须说点敏捷，说点XP。
其实真正使敏捷成为一种系统化说法的实践，是产生于IBM的一次方法改革实践，也就是水晶系列的调查和设计。cockburn在这个时候真正的把敏捷的理论做了总结和发挥，从而使方法论从欧洲色彩浓厚的UP又回到了美国色彩浓厚的美洲。

如果牺牲程序员的乐趣可以产生出和高质量的软件,为什么不这样做. 软件公司不是为程序员的工作乐趣而存在的.

不要说软件公司，就是包工头也要使下面的工人感到某种乐趣，要以情动人，这样的包工头才能从10个人的队伍到50个人到100个人，到公司，才能使自己多赚更多的钱

我家乡有很多人出去，没有文化，没有关系，没有资金，但其中有些人能够从一个挑沙子的变成腰缠万贯甚至亿贯的原因之一是他们有自己的凝聚力，别人愿意帮他们干。（当然不是全部的原因，但在早期发展的过程中完全靠人帮人，因为他没有关系、没有资金）

至于软件公司的管理如果不考虑程序员的乐趣，那肯定是失败的，不长久（不用说10年、20年，2、3年你就失败了）

不可否认在短期看某种措施会有效果，所以有人就会说“如果牺牲程序员的乐趣可以产生出和高质量的软件,为什么不这样做. 软件公司不是为程序员的工作乐趣而存在的.”但是他忘记了，用户也是人，客户也人，没有乐趣的人是不能为别人制造乐趣的，除非那些人本身是一种道德败坏的人。一个软件公司，或者我们干脆说一个组织，如果不能为这个组织的成员带来某种乐趣，让他们达到某种满足，这样的组织就不会有存在的基础。
日本人的方法之所以从来就没有成功过，原因大概就是如此。因为他们没有产生过真正高质量的软件，只产生过“软件工厂”、第五代计算机这些高水准的梦话。

potian和胖子说的对,我绝对同意.  我那句话的意思是觉得dlee说的话有太多程序员中心论味道了,而且推理有些偏离了,虽然我也是程序员,但我可不认为公司要围着我的感觉打转,有些事就是不开心的,比如改BUG或者程序后期的违护.呵呵.
   说到IBM,我现在正在IBM中国研究院做外包,6个程序员做一个研究型的小产品,我没看到RUP也没看到XP,  :-) ,  记得有一篇介绍打魔兽的人族高手,被誉为人族皇帝,他说:他没有什么固定套路,一切因对手而相应采取不同的战术.  无论是RUP还是XP一切都是实践总结出来的理论,不必拒泥于其中,我和过一个通了CMM5的加拿大公司的程序员交流过,他认为CMM5不过如此,我是没有过CMM的实践,不敢妄加评论. 但不可否认,国内很多所谓过CMM的企业,都是为了帖金而已.这是题外话
    大家想过没有,中国文化和外国文化是不同的,中国人和外国人也是不同的,对不同人生搬同样的方法就会产生问题,软件工程是一种管理,所以也是管人,即是管人就应该根据人之不同,项目之不同,而有所变化.所以当你选择RUP还是XP,请先问自己对RUP和XP的核心思想很了解吗?对你自己的团队和项目目的和要求了解吗? "实事求是" 老毛说的这句话是真理.
    RUP是做大项目的一个比较成熟而且得到实践证明了的方案,大项目不是指什么上千万或上亿的项目,IBM卖台大型服务器都可以上千万了(上亿的项目也许就几台或几十台服务器),政府的项目更是搞钱而已(这个我可是有深切体会),一千万的项目也许才10个不到的程序员在做.我这里的大指软件开始项目人员达到50以上的项目(这个50数目只是一个大概).
   XP我觉得他的思想中的一些元素真的很好,可惜没机会实践,但公认是比较适合小团队,我的理解也是适合小团队.
   RUP有适用于小团队的精减版,XP也有象前面一位老兄说在用于做大项目的案例,这本就不稀奇,它们本就是有交集的,也是有互补关系的.
  
   还有我就是觉得在这个帖的讨论太泛泛而谈了(包括我自己的发言),争论完了也就完,如此而已, 为什么不具体拿出一个成功或失败的案例来分析呢? ----只是建议

一听这句话就知道你没有任何的管理经验。你对管理的理解还停留在美国 30 年代泰勒的水平，连戴明都没有超越。

“程序员”这个称呼 8 年前对于我来说是个神圣的称呼，至今仍然是这样。

glchengang
对你自己不太理解的事情就不要做结论性的发言。
我们说的大项目，不是说钱多的项目，而是指参加的人数多，周期常的项目。实际上RUP由于其对于architecture的支持不够好，对于大型和超大型项目他是不适合的。而XP虽然还没有很多大型项目的经验，但是其所带来的效率，使其可以完成同等人员，同等时间，比RUP所完成的功能规模更大的项目。所以很多时候XP的一个小型项目，就是RUP的一个大型项目。
其实你也说了你和IBM打交道并没有感觉他们在使用XP还是使用RUP，这很正常。一个软件公司如果没有最近的方法系统，这个软件公司就肯定不能称为成熟的。所谓从这一点上说，凡是通过CMM的评估，并继续进行评估的公司也都是不成熟的。而实际上CMM5又怎么样，无非是一种对于外包公司的评估罢了。而软件外包这样的事情在我看来就正好说明其组织开发能力的落后于不成熟。
根本原因还在于我们对软件的根本矛盾的理解问题。可以说绝大多数人类的产品都是以用户为核心的，但是惟独软件、小说、电影、音乐这些人类智力创造性的产品，需要以它的生产者为核心。理解没有银弹，就会自然的得到这个结论。软件公司的核心就必须以程序员为核心，而不是以资本或者管理为核心。只是由于国内的愚蠢的老板和别有用心的鼓噪者太多，才把这个问题搞得不被接受。

呵呵,你怎么就知道我没有任何管理经验呢? 其实我在深圳做过一年的部门经理,十五个部门成员,做一个近千万的项目(和我说的一样硬件就占了五百万以上), 那个公司就在深圳南山科技园不过我管得不好,也可以说我没有管理经验吧.  
      当我辞职的时候,我的朋友说你可以找起点更高点的工作了,但我还是选择来了北京并且从头开始,做一个程序员,再回头来温习技术.  老实说我在深圳工作了三年,普遍感觉程序员的软件工艺太粗糙(当然有高手,不过我没发现),  我的以前那个公司的同事后来都离了职,其中一个现在在中国移动做DBA,一个在新加坡做软件开发,也算水平不错的了,但当时我的体会他们还是太粗糙. 
     可能我前面说公司做事不是以程序员的乐趣与否为中心的,让人误解了我,我说了我同意胖子的话,所谓管理就是要使被管理者发挥其最佳状态,并将所有管理者的工作合理安排协调到一个方向上, 当然在一个软件公司让程序保持心情愉快是很必要的.  但现在有几个软件公司是这样的呢? 你的公司是吗? 是,那我祝贺你. 我在IBM工作,感觉这里是这样的,至少晚上加班会有150%的加班费.  这里谈到的又不是软件工程了,而成了公司管理的讨论, 呵呵,跑题了.
    在IBM我在的这个Team,我没有看到RUP或是XP,或是其它的,不过他们是照着软件工程的路子走的,在这里对需求极度的重视,需求是由TEAM Leader带领几个博士硕士用两个月做的出来的, 然后软件的设计由一个北大数学系出来的牛人做的设计,他是我至令见过的程序员中最牛的人,设计做得很精妙. 而我只是一个小小的代码录入者而已. 这里代码工作量都有很好的安排,有时间点,后期有专门的测试人员全职负责测试, 这里是的的确确的软件工程在里面. 还有人性化的管理,当team leader看到我们太辛苦里,甚至上个月双休日时又多放了两天有薪假.  但我在这里看不到什么RUP或XP的大帽子在上面,他们也从不提这些东西(仅指本人所在团队) ,  我以为只有初哥初姐才去照搬什么RUP或XP的条条框框,高手总是能吸收更多的这些东西的精华做到依据实际情况灵活运用. 所谓运用之妙存乎一心, 想想不就是这样的吗?
    我没有参加过20人以上的大项目,所以软件工程方面,我想我是没有太多的发言权的, 但就国内各公司的软件工程规模,20人以上程序员的有多少??? 所以我还是会选择这样的道路: 不搞虚浮的CMM,多关注些软件工艺, 到国内软件规模起来的时候再玩CMM不迟

     这里观点我最赞同的是"凤舞凰扬",他说的话我99%同意.

其实工程的大小是很难判断的，由于你的组织的效率不同，这就更加困难。
但是越是大型的组织，需要在管理上进行的工作也越多，这个是不会有多少人出来反对的。而一个组织需要自己有独具特色的方法，也是没有人会出来反对的。问题在于我们如何建造这样一个方法。
学习别人的成型的方法，或者从这些成型的方法中萃取自己有用的部分是一个建造自己方法的途径。IBM在不同的时期产生了多种方法，比如现在最有名的是CRM，但是这并没有让他们就全面CRM，停滞不前。问题在于我们是不是以建造更好的程序为目标，还是以达到某种软件工程的所谓标准为目标。其实尊重软件工程的最好方法，我认为就是少说软件工程，多关注软件工程的目标－－建造质量更好的、成本更低、功能更强大的软件。
很多时候作为一个组织的管理者，往往为了达到自己的目标，而忽略了组织的目标，从而使管理侵犯了生产的利益。这些管理者还往往强词夺理的说，这是组织的要求。然而组织的要求往往是这些人最不感兴趣的那部分。