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

多关注软件工程的目标－－建造质量更好的、成本更低、功能更强大的软件。

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

凤舞凰扬
你说的功能增量开发（这个词我想才是你应该的意思），是建立在对系统功能很好的划分粒度的基础上的，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又回到了美国色彩浓厚的美洲。

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

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

这里有几个关键的问题:
  1. 用软件工程的Best Practice去管理"软件工艺"能管好的项目可以吗(前提是能够达到同样的生存要求,比如 Time & Budget,下同)?
  2. 用"软件工艺"的Practice软件工程的观点去管理能管好的项目可以吗?
  3. 如果两个问题大答案都是no的话,那么那种方式改变一下,花费代价更小的能够使用管好另外一种项目?或者是两者根本没有改变的可能性?
  4. 假设融合后的机制更能管理好项目,那么这种融合的项目会更趋向于工艺还是工程派?(ie, 更像爸爸还是更像妈妈?)
  5. 两种方式,尤其是大项目的方式,当中很多假设的时候,比如文档要全,那么制作和同步文档的花费和文档的详细程度之间到底有什么样的数量关系?和它的benefit又又什么样的数量关系?  各种工艺数据和实例数据,大家求证的可能性或者实践的机会有多大?工程量决定的最最因素是什么?(我的答案是50%工艺,50人的素质)

自从和他工作过以后,才知道,原来理想中的"PM"就是这样的.管他什么专家,其实,聪明和常识以及工作经验才是真正高素质人才和成功项目的不变因素,其他一切都真是"术"的一种而已.

一个项目成功与否的因素怎么可能纯粹在人那？

     你这是典型的以点概全了，一种纯粹的英雄主义！一个项目成功与否的因素怎么可能纯粹在人那？（有这样的高手自然好）我不想引用CMM的概念去反驳你什么，避免带来更多的对于CMM的讨论。
    不过最起码一点，把工程当作“术”，这是你最大的误区。

    回答一下liloboy很有意思的提问。
首先，没有任何一个人在项目最初就能判断和确定何种管理能管理好项目。
其次，一个项目的成功不会是纯粹管理理念的问题，更多的是来自于管理的实践。也就是说究竟像谁（工程或者工艺）不是绝对的，所以我才强调两者的充分性，而非必要性。
最后工程及工艺之间的量化差是需要进行数据累积和统计分析的（在这一点上是工艺和工程最大差别之一）。这个数值因公司而异，因项目而异，因员工而异，但是长期的统计分析值会在一个区间（这也就是为什么有些IT企业已经开始6σ的认证）。
软件工程和建造工程当然不一样，怎么能够照搬那？但是工程的概念对于任何的工程实践都是一样，所以ISO可以通用，6σ可以同样，采样分析也可以同样（不同的只是中间的指标和比重不同罢了）

我想起《最后期限》里面Mr. T说的一句话（第二章）：所谓管理，就是（1）找到合适的人；（2）给他分配合适的工作；（3）保持他们斗志昂扬；（4）保持团队凝聚。其他的，都是“案牍”。