| 作者：张恂 发表日期：2007 年 4 月 |
更新日期 2007-5-13 11:31:07
 |
[全程建模]响应张恂之《青润的《中国软件工程应用技术调查报告》》第四篇——迭代与交付周期
今天终于在张先生的页面里看到了一些关于响应的更新，我这里也一篇一篇回复。这里先谈一下关于迭代与交付周期的问题。
说实话，在这篇响应文字中我仍然没有看到任何实际项目的数据分析，而所有的内容都是张先生一厢情愿之猜想，比如：关于我是否知道迭代，关于RUP还是因为我的全程建模造成交付时间延长的问题。
张先生的原文引用
“
评青润的《中国软件工程技术应用调查报告》
[访问量:1651]
—— 这段明显是胡扯！
作为一名研究 RUP 的专家应当知道，RUP 是一个过程的框架（青润已经提到了）。Framework 是什么意思？既然是框架，就意味着丰俭随意，既可以定制出 heavyweight RUP，也可以定制出 lightweight RUP（比如 Agile UP），不需要我引用国内外的著名文献和案例了吧。RUP 框架和 RUP 过程是两码事。事实上，经过这些年的发展，统一过程（UP）已经发展成为一个过程方法的大家族。
作为一名 RUP 的实践者，应当知道实施 RUP 通常都需要定制！而 RUP 中的绝大部分工件、步骤和角色都是可选（Optional）的，它们摆在那儿的目的只是作为工作指南、方法指南，需要用的时候就可以去参考。就像 MSDN Library，RUP 框架同时又是一个丰富的过程知识库。没有人会觉得 MSDN Library 很笨重，有人会质疑图书馆很笨重吗？
RUP 怎么去和 XP 比较？XP 是一个具体的过程，而且比较严格，有那么 12 条军规（老版本），如果你做不到那关键的几项，项目就可能面临重大的风险。RUP 是一个灵活的、抽象的框架，既可以这样，也可以这样，你怎么去比？我们应该从 RUP 框架中定制出一个轻型的过程（实例）去和 XP 比，就像 Robert Martin（Bob 大叔）曾经调出的鸡尾酒（过程） - dx 那样。
所以，当青润给出“RUP 过程本身的复杂度和管理上的重量”、“国内从大型企业到小型企业都无法承受”的论断时，我给予了“胡扯”的评价。事实上，RUP 过程既可以是重型的（重型的并非不好，关键看项目的需要），也可以是轻型的、敏捷的。从青润的介绍来看，他好像有过 RUP 方面的实施经验，大概均是些失败的重型 RUP 案子。他对 RUP 的这种片面理解和曲解，对于 RUP 的本质、精髓和 common sense 的无知，出乎我的意料。
在 4 月 7 日的回复中，青润再次提到“ 应用 RUP 等重量级过程模型的确可以在一定程度上提高软件质量”，说明在青润的脑子里：RUP = 重量。这里再重申一遍： RUP 是个一个丰富而灵活的过程框架，不是一个重量级过程！
到今天，我差不多已做了 8 年的 UP/RUP 咨询，这里面既有国有企事业单位，大型上市公司，也有民营企业，外资企业；既有大型企业，也有中小企业；既有实施了 CMM/CMMI 的企业，也有采用了现代敏捷方法的企业。我参与咨询、评审、服务过的项目从几十万、几千万到几个亿的都有，涉及的行业、项目、规模、地域类型广泛，RUP 均能和这些项目很好地契合，前提是你需要认真地学习了 RUP，对 RUP 有正确的理解和认识。我的亲身实践经历和所见所闻，说明了 RUP 具有广泛的适用性，同时也符合国际主流软件工程界对 RUP 的认识和一致看法。
推荐大家读一读我两年前翻译的 Craig Larman 的文章《 RUP 实施之夺命七招》。
那么，青润在回复中提到：
他遇到的究竟是什么问题呢？为什么会让他得出有关 RUP 的错误结论呢？解释如下：
首先，青润声明他曾经“亲身参与过全程应用 RUP 的项目”，并且以他“应用 RUP 的经验分析认为：应用 RUP 等重量级过程模型的确可以在一定程度上提高软件质量 ...”。可见，青润把 RUP 当作重量级过程模型（需要完成大量的步骤，提交大量的文档）是确凿无疑的。可问题在于，根据青润的经验，为什么在应用了 RUP 之后，第一次交付期会延长 20-30%？
熟悉 RUP 的人知道，迭代、递增式开发是 RUP 的一个基本特征，而且对于固定交付期、固定预算（fixed time、fixed budget）的项目，RUP 也有很好的解决方案。在时间、成本固定的情况下，可以通过调整（缩减）交付内容以达到按时交付，这是现代软件项目管理的一项基本常识。所以，如果正确运用了 RUP，系统的第一次交付期是无须延长的（fixed time）。所以，说什么“因为应用了 RUP，导致交付期、成本都增加了 20-30%”，也是胡扯，这些项目的失败（延误、超支）恰恰是因为没有正确地应用 RUP。
青润还提到由于“这个时间的延长，会让用户感觉到他们始终没有看到软件产品”。为什么应用了 RUP，用户会“始终没有看到软件产品”？我猜，大概是因为青润不知道 RUP 过程应该迭代，用户“始终看不到软件产品”的过程不是 RUP。
青润把自己在实践项目中遇到的挫折、对 RUP 的误解和误用当成了 RUP 的问题，这显然是错误的。这些问题的造成，我想与青润误把 RUP 当作重量级过程、瀑布式过程有关，也可能与青润自创的全程建模方法有关。在我看来，“全程”两个字本身就带有过度建模的倾向。青润显然也不知道，应用 RUP 过程，可以在规定的时间内交付产品，客户不可能一直看不到软件产品。提倡对复杂软件系统进行 uml 可视化建模固然是 RUP 的一大特点，但 RUP 同时也非常强调通过迭代（编程实现和测试）尽早向用户交付稳定的架构和产品。
过度建模不是 RUP，我们不能把凡是有 uml 建模的项目都叫做 RUP 项目。青润有没有胆量承认：20-30% 的成本和时间增加是不是由于你的全程建模造成的呢？
从以上讨论和分析，我得出的结论是，青润基本上不懂 RUP，或者说缺乏对 RUP 正确、全面的了解，所谓的“亲身参与过全程应用 RUP 的项目”的说法是非常可疑的，这样的项目或许只能叫做“全程建模”项目，而根本不能叫做 RUP 项目。这就是我对事实真相的看法。
<首页> <上页> <下页> <末页> 第 1/10 页 前言 第 2/10 页 胡扯一、XP 的普及度 第 3/10 页 胡扯二、RUP 在国内的适用性 第 4/10 页 胡扯三、中国有无软件架构师 第 5/10 页 胡扯四、项目管理的普及度 第 6/10 页 胡扯五、白盒与黑盒测试 第 7/10 页 胡扯六、自动测试工具的普及度 第 8/10 页 胡扯七、XP 与自动测试 第 9/10 页 胡扯八、测试的认同度 第 10/10 页 胡扯九、迭代与构建频率
“关于 RUP 相关数据的评论：从软件企业的开发过程和实践来看，完全采用
RUP 的过程框架进行开发在中国国内是不太现实的，因为
RUP 过程本身的复杂度和管理上的重量是国内从大型企业到小型企业都无法承受的。”
—— 这段明显是胡扯！
作为一名研究 RUP 的专家应当知道，RUP 是一个过程的框架（青润已经提到了）。Framework 是什么意思？既然是框架，就意味着丰俭随意，既可以定制出 heavyweight RUP，也可以定制出 lightweight RUP（比如 Agile UP），不需要我引用国内外的著名文献和案例了吧。RUP 框架和 RUP 过程是两码事。事实上，经过这些年的发展，统一过程（UP）已经发展成为一个过程方法的大家族。
作为一名 RUP 的实践者，应当知道实施 RUP 通常都需要定制！而 RUP 中的绝大部分工件、步骤和角色都是可选（Optional）的，它们摆在那儿的目的只是作为工作指南、方法指南，需要用的时候就可以去参考。就像 MSDN Library，RUP 框架同时又是一个丰富的过程知识库。没有人会觉得 MSDN Library 很笨重，有人会质疑图书馆很笨重吗？
RUP 怎么去和 XP 比较？XP 是一个具体的过程，而且比较严格，有那么 12 条军规（老版本），如果你做不到那关键的几项，项目就可能面临重大的风险。RUP 是一个灵活的、抽象的框架，既可以这样，也可以这样，你怎么去比？我们应该从 RUP 框架中定制出一个轻型的过程（实例）去和 XP 比，就像 Robert Martin（Bob 大叔）曾经调出的鸡尾酒（过程） - dx 那样。
所以，当青润给出“RUP 过程本身的复杂度和管理上的重量”、“国内从大型企业到小型企业都无法承受”的论断时，我给予了“胡扯”的评价。事实上，RUP 过程既可以是重型的（重型的并非不好，关键看项目的需要），也可以是轻型的、敏捷的。从青润的介绍来看，他好像有过 RUP 方面的实施经验，大概均是些失败的重型 RUP 案子。他对 RUP 的这种片面理解和曲解，对于 RUP 的本质、精髓和 common sense 的无知，出乎我的意料。
在 4 月 7 日的回复中，青润再次提到“ 应用 RUP 等重量级过程模型的确可以在一定程度上提高软件质量”，说明在青润的脑子里：RUP = 重量。这里再重申一遍： RUP 是个一个丰富而灵活的过程框架，不是一个重量级过程！
到今天，我差不多已做了 8 年的 UP/RUP 咨询，这里面既有国有企事业单位，大型上市公司，也有民营企业，外资企业；既有大型企业，也有中小企业；既有实施了 CMM/CMMI 的企业，也有采用了现代敏捷方法的企业。我参与咨询、评审、服务过的项目从几十万、几千万到几个亿的都有，涉及的行业、项目、规模、地域类型广泛，RUP 均能和这些项目很好地契合，前提是你需要认真地学习了 RUP，对 RUP 有正确的理解和认识。我的亲身实践经历和所见所闻，说明了 RUP 具有广泛的适用性，同时也符合国际主流软件工程界对 RUP 的认识和一致看法。
推荐大家读一读我两年前翻译的 Craig Larman 的文章《 RUP 实施之夺命七招》。
那么，青润在回复中提到：
关于这段文字是不是胡扯，我有一个个人看法需要说明。
我曾经 亲身参与过全程应用 RUP 的项目实施，在这个项目中感觉到了 uml 的好处，后来也主动的推动了 uml 在项目中的实施，在国内的工程项目中经历了大到合同额接近两千万涉及到 11 个省级电信公司和电信集团公司的项目小到几十人天的项目几十个。
从我对国内软件企业的了解和对客户方耐心与耐性的认识，以及我应用 RUP 的经验分析认为： 应用 RUP 等重量级过程模型的确可以在一定程度上提高软件质量，但是，要在开发周期上，尤其是第一次交付前的开发周期上比原始的开发过程相对有所延长（大概要延长 20% 到 30%），而这个时间的延长所带来的第一次交付的成本也相应提高（对比时间周期的延长，这个提高也在 30% 左右，这两个都是估计数字，请勿追究其准确性）。
由于曾经的国内软件企业的混乱管理和信誉度低，使得目前的用户更希望的模式是：合同签署，软件就交付，合同就付款。而 这个时间的延长，会让用户感觉到他们始终没有看到软件产品，而产生相应的担心和对开发商的不信任。几乎所有的合同都会因为用户方的要求而定下一个不合理的交付时间。
所以，基于这种分析，我认为我的这段看法不是胡扯，而是由我的项目经验，乃至很多同行第一线的软件开发者的经验积累而得到的，我相信只要是在工程软件项目第一线参与过开发的技术人员基本上都会有同样的观点。
我曾经 亲身参与过全程应用 RUP 的项目实施，在这个项目中感觉到了 uml 的好处，后来也主动的推动了 uml 在项目中的实施，在国内的工程项目中经历了大到合同额接近两千万涉及到 11 个省级电信公司和电信集团公司的项目小到几十人天的项目几十个。
从我对国内软件企业的了解和对客户方耐心与耐性的认识，以及我应用 RUP 的经验分析认为： 应用 RUP 等重量级过程模型的确可以在一定程度上提高软件质量，但是，要在开发周期上，尤其是第一次交付前的开发周期上比原始的开发过程相对有所延长（大概要延长 20% 到 30%），而这个时间的延长所带来的第一次交付的成本也相应提高（对比时间周期的延长，这个提高也在 30% 左右，这两个都是估计数字，请勿追究其准确性）。
由于曾经的国内软件企业的混乱管理和信誉度低，使得目前的用户更希望的模式是：合同签署，软件就交付，合同就付款。而 这个时间的延长，会让用户感觉到他们始终没有看到软件产品，而产生相应的担心和对开发商的不信任。几乎所有的合同都会因为用户方的要求而定下一个不合理的交付时间。
所以，基于这种分析，我认为我的这段看法不是胡扯，而是由我的项目经验，乃至很多同行第一线的软件开发者的经验积累而得到的，我相信只要是在工程软件项目第一线参与过开发的技术人员基本上都会有同样的观点。
他遇到的究竟是什么问题呢？为什么会让他得出有关 RUP 的错误结论呢？解释如下：
首先，青润声明他曾经“亲身参与过全程应用 RUP 的项目”，并且以他“应用 RUP 的经验分析认为：应用 RUP 等重量级过程模型的确可以在一定程度上提高软件质量 ...”。可见，青润把 RUP 当作重量级过程模型（需要完成大量的步骤，提交大量的文档）是确凿无疑的。可问题在于，根据青润的经验，为什么在应用了 RUP 之后，第一次交付期会延长 20-30%？
熟悉 RUP 的人知道，迭代、递增式开发是 RUP 的一个基本特征，而且对于固定交付期、固定预算（fixed time、fixed budget）的项目，RUP 也有很好的解决方案。在时间、成本固定的情况下，可以通过调整（缩减）交付内容以达到按时交付，这是现代软件项目管理的一项基本常识。所以，如果正确运用了 RUP，系统的第一次交付期是无须延长的（fixed time）。所以，说什么“因为应用了 RUP，导致交付期、成本都增加了 20-30%”，也是胡扯，这些项目的失败（延误、超支）恰恰是因为没有正确地应用 RUP。
青润还提到由于“这个时间的延长，会让用户感觉到他们始终没有看到软件产品”。为什么应用了 RUP，用户会“始终没有看到软件产品”？我猜，大概是因为青润不知道 RUP 过程应该迭代，用户“始终看不到软件产品”的过程不是 RUP。
青润把自己在实践项目中遇到的挫折、对 RUP 的误解和误用当成了 RUP 的问题，这显然是错误的。这些问题的造成，我想与青润误把 RUP 当作重量级过程、瀑布式过程有关，也可能与青润自创的全程建模方法有关。在我看来，“全程”两个字本身就带有过度建模的倾向。青润显然也不知道，应用 RUP 过程，可以在规定的时间内交付产品，客户不可能一直看不到软件产品。提倡对复杂软件系统进行 uml 可视化建模固然是 RUP 的一大特点，但 RUP 同时也非常强调通过迭代（编程实现和测试）尽早向用户交付稳定的架构和产品。
过度建模不是 RUP，我们不能把凡是有 uml 建模的项目都叫做 RUP 项目。青润有没有胆量承认：20-30% 的成本和时间增加是不是由于你的全程建模造成的呢？
从以上讨论和分析，我得出的结论是，青润基本上不懂 RUP，或者说缺乏对 RUP 正确、全面的了解，所谓的“亲身参与过全程应用 RUP 的项目”的说法是非常可疑的，这样的项目或许只能叫做“全程建模”项目，而根本不能叫做 RUP 项目。这就是我对事实真相的看法。
”
评论
青润不懂得什么是迭代！
这句话反而问得我不知道张先生对迭代的定义是什么了，也许我不懂得张先生的迭代是什么，但是我相信我很清楚迭代的意思。
我知道张先生这里说到的是关于交付的问题，可是在国内的项目进展过程中，用户往往要求的是直接见到全部可用的软件版本，而不是一个一个的中间发布版本，这一点的偏差，我甚至有点怀疑张先生是否有亲自参加过一个完整的国内软件产品项目的开发经验！！！
只要是参加过实际软件需求、分析设计、编码测试的人都知道，第一次交付意味着什么。
而且在我的文字中多次表达过这样的观点：第一次交付的时间如果采用RUP的过程哪怕是裁减的过程也会比我们相对较为混乱或者不完全采用RUP的过程比较起来，要有所延误，这个延误的时间一般在三分之一左右。也就是说，10个月的项目大概要延期3个月才能进行第一次交付。
注意，这里的交付必然是完整版本的，因为，在中国的环境下你不可能拿着一个不完整的版本交付给最终用户，你如果敢这样做，客户就敢直接把你的软件扔进垃圾箱！
当然，这个交付的版本在用户那里还是不能完全达到用户要求的，还是需要修改，还是需要根据用户使用后的感觉进行调整、优化、修改的。
青润的交付延迟是因为他本人的全程建模的建议。
这一点，我可以告诉张先生，恰恰相反，正因为采用了我的全程建模的方法，才可以基本上让我的交付时间与传统的软件开发时间十分接近，几乎不需要延迟。
另外，听过我的培训的朋友都知道，我会针对不同项目的不同阶段采用方法中的不同部分进行，并不会要求必须全部采用uml的表述方式来实现所有阶段，因为毕竟我们的技术人员对uml的熟悉程度还并不是十分高，他们的技能还需要提高（至少我所带过的两只应用了全程建模方法的团队中的实际情况就是这样的，这也是因为中国国内软件企业的不稳定性造成的）。
另外，我们可以作这样一个考虑，一个配合相对稳定和谐的团队，他们可以省略相当多的文档，而按照rup的建议，大量的文档是不可缺失的，甚至不可省略的，因为每一步的交付都有它必须存在的文档资料。在撰写和修改这些文档的过程中，就会产生相当多的人力和物力（注意，这里我并不是说写这些文档是无用的，而是说这些文档在一定的程度上可能会被人忽略，而由于团队的稳定而带来相应的节省），这难道不会造成交付的延期么？
而往往在实际的项目中，项目的交付是被指定的，我们可以因为一些原因而延期交付一些，比如04年初我们的一个软件版本的交付就因为非典而获益，得到了两个多月的额外开发周期，这使得我们的项目团队由死转生，否则，我们当时的项目团队是无论如何也不能在五月中旬交付电信集团所需要的软件版本的。
结尾
我还是希望张先生拿出数据来，而不是仅仅在这里做空对空的推理，或者空对数据的推理，这样不是一个实际做事情的人应该说的话或者应该写的文字。
我再次强调：一个做实际事情的人应该是拿数据来说话的！