作坊与工厂距离多远，你只要设想一下你公司最理想的工厂式开发是什么样子，然后看看到那时需要哪些人才，什么样的公司文化，多大规模的软件工程库，再看看你现在的情况，你就知道有多远了。
4. 过度工程的危害
那么什么是过度工程呢?如果你的项目从现在开始编码一个星期内就可以完成，那么需不需要风险预警呢?一般是不需要的，因为项目周期越短，建立风险预警制度的代价就越高，这里的代价是指该项活动在这个项目周期中所占的时间比例。当警报出现时，已经半个星期过去了，但对于很多教条主义者来说，风险预警是必须的。而对于我来说，这就是过度过程，在一个项目中，做了这个项目完全不需要的工作。 再比如，使用RUP，每当我看到有人诚惶诚恐地按照RUP的步骤一个图一个图地画下来，我总觉得很可笑，他可能不知道，当他刚画完实体图的时候，其他工程师已经完全领会他的设计了，我不知道如果我用汉语表达完我的意思后，是否还需要再用英语表达一遍，对于很多经验丰富的程序员来说，有了实体图，最多再加一个状态转换图已经足够开始编程了。而且，使用图形和文档表达出的类的接口设计和关系是否比直接用程序表达出的更容易读，我看未必。XP的创始者说：为什么要写文档呢?代码就是最好的文档。从一定程度上，我非常赞同这样的观点。现代软件工程发展的趋势之一，便是越来越承认现实，承认人类的有限理性。
项目的主要目标是什么，是按时按质按预算地完成软件产品，所有的活动都应该围绕这个目标进行。所以，如果你以前已经做过很多类似的项目，你知道在这样的时间、资源约束下，要想完成目标必须采用什么样的开发过程，那么你是不是还需要引经据典地写报告证明你的想法，等待另一个并不比你经验更丰富的人花上一个星期来为你做评审，本来一个小时就可以做出的决定因为流程教条主义者的约束，连写报告你需要花上两个星期。还有评审活动，做评审的往往是一些不在你项目组织中的所谓技术权威，他们也许在技术上是权威，但对你的项目却一无所知，如何评审?走过场而已，但却为以后的责任推诿留下后门。一个活动是否应该保留或应该如何进行，要完全以是否有利于项目目标为准则。但遗憾的是，别看国内项目大多整体缺乏工程规划，但这种局部活动的过度工程却比比皆是。 那么过度工程有害吗?有害!软件工程书上讲了很多如何控制风险的工程化方法，却没有讲如何保持程序员的创造热情和工作激情。软件开发讲千讲万，离不开程序员的创造性活动，你可听说过哪个优秀的软件不是靠一些程序员主动加班加点的超常劳动作出来的?一个团队中，最重要的永远都是程序员的热情，这也是一切工程化方法需要注意的，也是所有项目管理艺术的主题之一。 因此，软件工程的实践程度对于项目来说够用即可。那么多少算够用呢?这要考虑项目可以承受多大的失败风险。也就是说对风险的控制做到什么样的程度。对于你的项目，你是准备跑还是走?如果跑，打算跑得多快?我认为，所有的软件开发，所有的项目管理，与其谨小慎微战战兢兢地向前挪动，远不如在可控的奔跑中把握平衡，那样会更容易一些。 大多数的软件工程方法，都是为了提前知道哪些以前担心发生的事情真的发生了，但天下没有免费的午餐，任何东西都有代价，为了这个“提前知道”，我们需要付出的是可能的过度工程以及其带来的副作用。因此风险控制也不能无限制，需要权衡。
还有很多工程方法，比如说文档是为了交流，但是如果一个项目组中只有你和测试工程师，还需要使用“BUG报告->修改意见->评审->反测报告”的方法确认吗?遗憾的是，这样的例子在国内的一些软件公司，甚至是外企，在真实地发生着。
而很多程序员认为软件工程太虚也恰恰是因为这个。软件工程书上讲了很多方法，但没有让你每个环节不分重点地执行啊!你可以把它当做教科书，可以把它当做技术词典，但就是不能把它当做操作手册!现在的RUP应用就有这种趋势，为RUP而RUP，为“规范”而“规范”。什么都全了，唯一没有的却是目标。
5. “流水线”的误区
传统的大规模工业化生产是采用按既定的流程流水线的制造产品。最初的软件工程的理想大概也是向此方向靠拢。但问题是，软件能否按照流水线方式大规模的生产?如果你认为长城不能被批量制造，金字塔不能被大规模生产，那么软件也不能被流水线开发。
对于软件开发来说，任何两个项目都不会完全相同，不完全相同的功能集，不完全相同的非功能性目标，不同的时间资源约束，不同的公司文化，不同的用户，新的技术，新的开发工具等等，所有这些都为软件开发制造了不确定性。为什么软件开发要以项目的方式进行，因为项目这种工作方式恰好就是专为那些具有唯一性和不确定性的工作所设立。
但现在很多软件组织的开发方式却是挂“项目”之羊头，卖“流水线”之狗肉。以为流程重于一切，以为只要按照RUP或其他类似的过程一步一步走下来，就一定会得到一个合格的产品。不错，如果仅以产品的功能来衡量，确实从统计意义上说会的，但别忘了，项目目标的是一个三维向量—质量，时间，预算。(后面的章节中会陆续谈到质量之于软件的重要性和开发速度之于软件的重要性，相比之下，因为软件产品边际收益的不确定性，预算反而有可能成为最不重要的一环。)。如果从统计意义上说，完全按照RUP或其他类似的软件工程方法亦步亦趋地做下来，进度表一定会失控的。
文章来源于领测软件测试网 https://www.ltesting.net/
