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

看了dlee老大的话，再看看自己公司的环境，两者是多么的相象啊。
我在想，有人善于做事情，而有人善于说，最后的结果是善于说的人在管着善于做事情的人。 而结果是，成功了是因为指挥得好，失败了便是因为没有做好。
不管对于软件工艺这个概念有多少种理解，可是至少我觉得，工艺是没有停留在口头上的，而是在于实践的。将软件设计与工艺向结合，崇尚积极动手，崇尚解决实际问题，我想这才是本源吧！

我大学毕业就在一个规范进行软件过程的企业中工作，不过我的观点并不认为软件工程如何强大，同样我绝对不否认《软件工艺》的作用。
   我觉得要理解一个软件系统的开发，两个因素历来是不能被忽视的，人才和控制（其实对于其他的工程都是如此，只是软件对人的依托更加重要和明显罢了）。我想dlee兄是赞成首先要抓人的，而那些附庸软件工程的人认为首先是要抓控制的。其实说白了，是双方的出发点不同。dlee认为，中国的项目组不大，管理太多，技术也就是工艺则会后退；而另外支持软件工程的人认为中国程序员的技术水平已经相当高（也就是认为比印度的高吧），或者理解为工艺不错，但是工程欠缺。双方的出发点或者说对中国软件的认识导致了这样的误差。
    一般说来，来自于大公司的程序员（应该说更加高级的软件人士）比较推崇软件工程，而一般在底层摸爬滚打出来的技术人员一般在意软件工艺。其实说白了，也就是高级钳工和管理人员的冲突。
    我只所以提出反对的声音，只是怕双方都走入极端，一个没有工程概念的管理团队永远是做不大，做不强的；而一个没有好的技术水平和合适的控制粒度的项目团队却是极其难以成功或者容易失败的。
    中国的软件业非常的浮躁，非常喜欢跟风，从最高层的领导到最低层的程序员都是如此，一个新的概念，一个新的观点，非常容易被一大群人翻来抄去，我始终觉得，不要轻易去批判一样东西，不要轻易去下达一个容易误导的观点（虽然我的态度经常被一些非常不喜欢就事论事的朋友批驳为永远只会谈概念，不过我想，这应该才是一个比较务实的态度）
    我只希望，论坛中会有一群朋友，笑看抄作，保持一份冷静，更全面地看待一个问题。

又是一个典型的故意矮化和曲解，动机很可疑哦。
不知道你究竟把 Bill Gates 列为哪一类人物，说说你的看法。

我想xp强调的东西应该是一个解决问题的方法，Martin Fowler在Kent Beck的TDD中谈到说是一种避免同时保持几个球在空中的思考方法。软件工程好象是首先假设了我们具有这种保持几个球在空中的能力，并甚至有对问题的预知能力；接着去谈论如何使用工程学的方法来做软件。
作为一个技术人员，我喜欢xp,最喜欢的是敏捷中提到的软件美学。

  呵呵，我不是曲解，也许我的话过于大了，不过我加了个前缀“一般说来”，不是指全部或者一定的。
  另外，你问我gates更看重什么，我可以告诉你，是工程，如果你有兴趣招招微软的面试问题，看看《程序员》杂志（我不记得是哪一期）关于微软招聘员工的情况，你就知道他看重什么了。

    very good!我觉得楼上这话说得非常好。作为我个人，从技术员的角度，从小型项目的角度，我偏向XP，偏向工艺。但是作为公司管理人员的角度，我又希望公司能够建立一套合适的工程。两者其实并不矛盾，并且应该相辅相成，只是在不同的时期，在不同的时候各有侧重。
   另外，XP也是工程的一种，连Rational公司的RUP创造者们都承认XP其实是RUP的简化版。UP、RUP、XP、敏捷过程其实都是方法论，真正需要的是靠人去融会贯通，而不是强来强借，到这里，我想，dlee的初衷也应该是这样的。

软件设计需要思维，思维过程是最难理解的东西。或者TDD,PP比其它方法有益于这种思维过程；所以或者软件设计需要TDD,PP。另外，很怀疑MDA的作用，怀疑它不过是使用一种不同于code的符号来表示设计，不过是用于表示设计的另一种形式的符号系统，对思维的过程起不到什么作用；但或者用于人与人，或者计算机沟通是很好的。

凤舞凰扬
我建议你去浏览一下MSF，你自然会明白MS是一种什么公司。而我想你也应该明白agile的很多方法都是来自IBM的实践。其实往往是那些大型公司的人才更喜欢敏捷之类的方法，而就是那些自己没有核心资产，没有方法的弱技术公司，才会去玩CMM之类的东西。因为MS和IBM从来都不缺少伟大的程序员，即使没有他们也可以使用各种方法把伟大的程序员收规他们的队伍。而那些弱技术公司，由于实力和能力的原因，他们不可能有这些伟大的程序员助阵，更不愿意把自己的程序员培育成伟大的程序员，所以他们才玩方法、玩过程。
一个公司敢不敢把自己的方法建立在依赖技术天才的基础上，本身就可以说明这个公司的管理水准是不是已经达到可以吸引和稳定这些天才的水平。越是这些技术、管理不行的公司，越是没有勇气去承认自己的管理和技术不行，他们才越是会依赖那些所谓的方法和过程。
rup认为xp是一种简化的up是在给up脸上贴金，up的约束性和可管理性根本就不可能达到xp的水平，即使是rup也不能和xp相提并论。并且我想你也不知道最早的坚定的xp的支持者，本身就是一个无技术背景的管理人，而且越是这些真的懂管理的人，才越是会喜欢xp这样的方法。因为这些方法所隐含的高交互，扁平组织，动态管理，都是现在管理学上真正流行的热点。

    呵呵，这个观点倒是蛮正确的，事实也的确如此。
   我不太了解MSF，所以也没有关注过，有空我会去了解。
   不过我想说的，XP其实有一个非常重要的前提，那就是项目比较小，同时同客户能够保持长期有效的沟通（甚至提出现场办公），它的另外两个非常重要的思想：项目组有效沟通、快速原型化（反复重构）。
   O6Z兄估计没有碰到过过上千万价值，三四十人以上项目组规模耗时要一两年左右的软件项目（比如深圳盐田港、澳门民政总署的项目），同时也是非现场办公的项目，我可以说，这样的项目，XP是不行的。一、项目组内很难进行全范围有效沟通，同时组员职责分工非常明确。二、项目规模大周期长，根本不可能快速原型化和重构，RUP的迭代思想在这里得到最大的发挥。三、需求的分析、架构的设计都需要经过反复的评估和审查，不能也无法像XP那样做出来不满意再重构的。
    RUP，要面对的就是这样的项目，要解决的就是这样的问题。这样的项目必须要有工程的概念，要有丰富经验的项目管理人才才能把握，不是有几个技术牛人就可以解决的。
    而中国，毕竟这样的项目少，所以dlee提出的一个观点就是反对有些人将工程强加至每一处，要适合中国的国情。
    我最后想说的是，我们反对RUP（CMM）的滥用，但是也不要过分夸大XP、敏捷过程。我们反对纯管理，但是也不要过分夸大技术。其实他们都相辅相成，兼容并绪，量体裁衣何尝不是一件好事呢？

xp目前用的大型项目，报道是美国的一个系统安全项目，80工程师，周期是2年，目前还在继续。并且不断有大型项目使用XP的报道出现。xp说的是在小型项目已经被正式的证实是有效的，大型项目由于其出现的时间较晚，所以经验还不是很多。当然如果拿FDD来比较，我认为XP的规模应该还是小。
而你说的“三四十人以上项目组规模耗时要一两年左右的软件项目（比如深圳盐田港、澳门民政总署的项目），同时也是非现场办公的项目，我可以说，这样的项目，XP是不行的。一、项目组内很难进行全范围有效沟通，同时组员职责分工非常明确。二、项目规模大周期长，根本不可能快速原型化和重构，RUP的迭代思想在这里得到最大的发挥。三、需求的分析、架构的设计都需要经过反复的评估和审查，不能也无法像XP那样做出来不满意再重构的。 ”是典型的不在状态的发言。首先快速原型的使用和项目的规模无关，并且越是需求不完整，沟通欠缺越是应该应该是使用。而RUP的对迭代支持的不好是一个被RUP最显著的缺点，而不是他的强项。至于重构的话，我可以认为你没有说过。至于RUP中所谓的ARCHITECTURE我认为只是一种玩笑，根本就是概念不同的一种误人子弟的歪理，至少这个方向我会去学习SEI的理论。
就目前情况看我逐渐的会成为一个XP的反对者，而不是支持者，当然我的角度是认为XP还太重了。对于RUP我建议大家还是去研究几下的好，很多东西想当然或者听RATIONAL的一面之词是不行的。