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

我不清楚O6Z兄对RUP的了解程度，不过至少在这一点上，兄台理解或者表达有误，RUP的精髓就是迭代，RUP中的每一个子过程或者环节都可以裁减，但是它的迭代的思想，螺旋型的软件开发模型是基本，怎么反而变成它最显聚的缺点了呢？
RUP作为一个软件过程，它只是UP的一种表示，也是众多软件过程方法中的一种，它自然不能适用所有的问题。不过一点，如果论实际应用的成功，它绝对比XP多（而在国内，确恰恰相反，说明什么了？）
以我的经验我的了解，RUP不是本身有缺陷或者其他怎么样（它只是螺旋型迭代软件开发过程的一种描述），而是中国的软件企业盲目地相信它，甚至滥用它。任何一个熟悉RUP的人都知道，除了迭代的思想外，它还包括角色、工件两个非常重要的描述。在RUP的文档里，角色是相当丰富，每个角色的职责要求能力都非常明确，而工件（主要是文档）也相当繁杂。所以要完成一个真正的RUP过程，起码需要保证一个项目组（及相关项目支持人员）有一二十人以上，而这在中国的项目开发中往往很难做到，所以出现了一个人担任多个角色，一个人要产生相当多的工件，就变成了为文档而写文档，为通过而进行评审（因为根本没有什么人可以来评），过程成了摆设，成了包袱，成了装饰。但是，这，并不是RUP的错，而是应用的错啊。
   这时，再回到我前面帖子说的例子，当一个项目组的成员职责非常明确，甚至严格的时候，那么它会在与项目组全范围内的沟通非常困难（程序员只关心实现，设计员只关心设计，需求人员只关心需求，当然他们需要沟通，但不是全范围的沟通，没有可能出现程序员去熟悉需求，讨论需求的情况。这其实也就是软件蓝领概念的来历）；其次，当项目组规模相当大的时候，每一个程序员所看到的代码只能是自己模块范围内的（其他的都是组件化，根本无法也不可能看到其他代码），不要谈系统级别的重构了。第三，当项目规模相当大的时候，无法做到快速原型化（这里的原型不是静态页面原型，而是XP提出的系统功能的原型），也无法像XP所期望的能与客户保持长期的直接沟通（XP中很明确的描述如果有可能尽量与客户直接面对面进行开发），需求的变更也是受到相当的保障（有兴趣可以了解RUP的需求变更）。
    我想，能在这里谈软件工程的，都是对软件工程有一些了解，并且在实际工作中感悟到了的，没有人会去照搬书籍或者某些人说过什么话的。我不太理解，O6Z兄是反感RUP在中国的实际应用（感觉dlee应该属于这一种）还是排斥RUP本身（这样的话，我觉得有些偏激了，尤其是作为软件工程论坛的斑竹）。一个合适的过程从来不是搬抄任何一个过程模型，而是根据自己公司的需要进行调节整理，汲取各个模型的特点和优势。
    正所谓，海纳百川，有容乃大，o6z兄，不是么？

严重抗议！请不要为我贴上某种标签，OK？
今天和 gigix 吃饭时我说，我觉得《软件工艺》很好，是因为这本书很好地解释了我们目前的开发方式和团队组织形式，使我们不必非要去向某种软件工程靠拢（不必费尽心机地向 RUP 靠拢，也许在你看来，这显然是一件不可思议的事情）。至于这本书是否适合你们的组织，要由你自己来判断。我并不认为它会适合所有的组织。
这本书中的很多内容在我的身边都可以找到实实在在的例子，我们一直在这样做，只是没有象作者总结的那样系统而已。

当然读这本书不过花费我一两天时间，即使读了也没什么可神气的。我们仍然需要切实地改善我们的工作质量，但是并不是按照软件工程的方式。

To: 凤舞凰扬

一千万的单子真的不算什么(指整个单子，不是单指项目的软件开发部分)，我想你可能接触跨国公司经验少一点，我HP的朋友，就是上次上海聚会最后做演讲的joe，他负责的项目没有千万级别以下的，全部都是千万以上的，大部分都是上亿的单子，这其中有给sina做的，有给江苏移动做的，有给教育局做的，哪个都是上亿的。

由于我并不是一个纯粹的开发人员，有些话我不好说。

不过你去问问gigix，他们给浙江某个地市的一个部门（在浙江只能排在中等水平）做的软件系统都比什么中国船舶工业总公司的财务审计项目要大。至于在富裕的城市，譬如杭州某个部门的综合管理平台，其中的GIS部分第一期金额就和Gigix他们那个系统的大小差不多。

政府部门里面有很多手段的，譬如和某个公司合作以后把整个项目的总体计划定下来，这个公司帮他们写标书，然后分割开来一个一个不大不小的项目招标，可以排挤小公司，也不会引起太多别的公司的注意。

当然这些还不是正式列入浙江省计划的项目，以前的总体投资我不清楚，但从2003-2007，浙江省有5大百亿建设工程，其中信息化是其中一个“百亿信息化建设工程”—每年政府在信息化上投入20-30亿资金，其中光光电子政务信息系统建设的资金大约是每年5-6亿，每次都是那10个左右的单位分掉的（业主单位也在10个左右），其中绝大多数还是少数几个集团下面的子公司做的。据2003年的总结好象最后的金额好像还是超过的。

XP和RUP的根本区别不在是否迭代或者是否重构这些细致末端上。XP的过程控制在某种程度上比RUP还要严格一点了

要理解XP，最关键的是要理解敏捷宣言。这就好比文艺复兴，并不是说文艺复兴时代的人用了和以前完全不同的语言来写诗歌，或者说诗歌的体裁和结构完全不同了，甚或是写诗的方法和过程完全不同了。

凤舞凰扬
就迭代的问题，我来给你做一个比较快速的解释，其余的关于RUP的架构混乱，测试支持不好，等等其他谈论比较多的缺点，有机会再讲。
首先迭代的定义，我们明确为按照计划，产生按照一定标准的最终产品的一个过程。螺旋模型则另外一个和迭代有某种相似性的东西，但是其根本不是一个迭代。具体的解释你可以看看《软件工程－java语言实现》P41的图。同迭代关系密切的是增量模型。
一个方法对于迭代是否支持，不在于他所说的承诺，而在于他是否提供了迭代所提供了良好的条件。迭代最重要的是对迭代计划的制定，而RUP对于里程碑的支持都是不到位的，对于迭代这种更小粒度的计划则更加差。其次迭代需要，对于对于其最终产品的标准进行细化的建造。RUP由于对于需求的解析粒度不统一，对于迭代计划和迭代结果的标准制定也不能提供充分的支持。其次RUP所言的阶段论，也使迭代的开展受到的阶段的约束。而同时其实RUP并不要求你的开发一定需要使迭代的，只要你按照他的阶段过程运行就是可以的，也就是RUP对于迭代是弱约束的。
鲜明对比的是敏捷系统对于迭代的强烈要求，并且我个人的观点敏捷方法的最明显特征就是小迭代的开发方式（这一点大家可以争论，但是不论如何迭代都是一种敏捷的最重要要求）。我们以XP和FDD来说明问题。首先XP的开发计划就是按照迭代制定的，FDD也是如此，也就是说在早期和最早期，这些敏捷方法就把所有的工作都落实到迭代的基础上，并且必须产生最后的产品。XP和FDD的基本上都是要求1－4周为一个周期，最多数的是2周。对于需求的把握XP和FDD从来就是在细小的统一粒度上进行的，XP的点是一种主观化的用例工作量计量方式，而FDD中的feature则是我见过的最好的计量形式。xp和FDD都要求开发必须是迭代形式的，并且无所谓的阶段说法的约束。
最后提醒你一下，很多敏捷方法都是来自IBM，而Borland也是一个敏捷的方法FDD，而rational其实也是很敏捷的，至少他们试图使自己敏捷起来。而现在最激进的敏捷者可以说是Highsmith和Jacobson,这两位大师都宣称要在敏捷的基础上发展出更加灵活的方法。
dlee看来在RUP上又一次误到了我，原来我计划的写一个系列的解释RUP文章看来还是有一点必要的，特别是最近某些大师也出来说东道西，我真的想要放下手头的计划，从新写一点RUP了。当然就目前情况，还没有这个必要，不过大家如果对RUP有兴趣，可以就不太大型的话题和我讨论，或者允许我对大型的话题采取这样简单化的发言。

robbin，搞错了。joe的项目和这里讨论的不同。主要是卖硬件设备的。不过，我lp在lucent的一些项目的确比较吓人。想想移动的收费的系统，这些系统的业务逻辑不复杂，问题是业务逻辑太多。业务逻辑多的直接后果就是系统复杂。软件项目和系统集成项目的差别还是比较大。

这本书已经全部读完，掩卷深思，觉得确实一本难得一见的好书。如果早读过这本书，我的技艺肯定会比现在精进的多。

庄表伟所质疑的这本书只有破坏没有建设我认为是偏颇的。这本书是有破有立的，差不多是提供了一个自给自足的理论体系（主要是从“工艺”的隐喻出发）。有些人对这本书的惊讶我认为与熟悉欧氏几何的人见到黎曼几何后的惊讶差不多。

唯一不足的是作者的少数观点过于理想化，例如作者所说的建造 20 年可用的软件那一段：

可是谁有能力能预测到 20 年后呢？而且从成本上来看，构造 20 年可用的软件的成本也是很难接受的。

另外不是每个学徒都可以成长为工匠的。有些初学者成为高手需要很长的时间，有些就根本不可能成为高手，他的性格决定了他对开发没有激情，只把开发看做是枯燥的工作。这样的人难道就简单地淘汰掉吗？一个公司全部由优秀的人构成（即使学徒缺乏经验，但是他的学习精神仍然使他成为一个优秀的人）听起来很不错，但是实际上从管理上来说是不大可能的。当然我还是愿意相信：只有无能的老师，没有带不出来的学生。老师如果都没有激情，如何让学生产生激情和兴趣呢？

总的说来还是瑕不掩瑜，尤其建议刚参加工作的网友们看一看。

我还是强调我们一个学会在没有银弹的情况下生存，并且应该努力做到没有银弹，而使用现有的技术手段消灭人狼。
关于政府的项目，其实政府也是有很多的难处，我们就不要太挑剔。有机会我可以给大家介绍一些这个领域的经验。
目前情况看，我的观点是：做正确的事情，比把事情做正确重要的多。也就是软件开发中战略层面的问题，比战术层面的问题，重要的多。或者说究竟是工程还是工艺，并不是最重要的问题。最重要的还是我们究竟要开发什么样的软件，而不是我们要怎么开发。这也就是Brooks的所谓概念完整性的内涵。这也是那些人不管怎么跳，也只能是针对银弹的种种说辞，无法动摇《没有银弹》这篇文章的内核的根本原因。

    呵呵，首先澄清这绝对时个我人理解，不是对你贴标签，理解有误了，敬请原谅，比如你看“UP、RUP、XP、敏捷过程其实都是方法论，真正需要的是靠人去融会贯通，而不是强来强借，到这里，我想，dlee的初衷也应该是这样的。”
    我另外说明我的态度，我是很支持XP的，另外我根本不会取向某种软件工程靠拢，甚至反感那些动不动就照搬这些东西人，不过一点，我不会因为这样而去反感软件工程（包括所有的过程）本身，我个人觉得我没有达到那样的境界，在这样的情况下（即算每次我的工程应用都失败，我都认为是我没有做好，因为有相当一部分也成功过，那为什么没有我），我只会去思考自己，思考自己所处的项目，思考自己所处的环境。比如说“淮南为桔，淮北为枳”，这并非种本身有问题一样。
    对你观点的理解，我认为是看重实质，不要被形式所扰，不知对否。