资深专家谈现代软件工程（续）

　　能不能具体介绍一下你们公司在组织和人员划分方面的情况。

　　邹涛：

　　目前有产品经理、项目经理、项目开发人员、测试经理、文档，还有最基本的五个模块，要细分还有很多角色。

　　提问：

　　我想问一个企业文化方面的问题。软件工程里面涉及到管理和人的问题，金山公司在国内软件业做得是最好的，管理和人还有激情，因为做软件过程中，激情是很重要的东西，你们在管理过程中如何协调管理、人和激情这三者之间的关系呢？

　　邹涛：

　　这个问题我只能从我自身来反应一下，可以说在中国恶劣的软件环境下，会来从事软件开发的一定是对软件充满热爱的，很有激情的，所以任何一个加入软件公司的年轻人当他刚刚走进这个大门时，他肯定充满激情的，但这种激情能维持到多久，这就涉及到对人员的管理。我们公司按我们雷总说金山是一个舞台，你在这个舞台上你唱戏，能唱多大就唱多大。这就是金山给员工一个非常好的前景，只要你愿意去做，只要做好，你就有前途的，我们的管理就是基于这个思想，紧紧围绕这个思想。

　　杨永生：

　　微软招人的时候会看看你是不是想做这个事情，还是仅仅因为是微软才来应聘。另外靠一套完整的机制，包括奖惩激励机制，以及使每个人感到被尊敬的公司文化。如果他有什么想法，可以加入产品中，或者可以去高层反映，主要是指这两方面。

　　王东临：

　　我理解他的问题是指软件开发在很大程度上还是有一定创造性的劳动，如何在规范化可重复性的过程中，避免对创造性的压制。

　　杨永生：

　　如果你仅仅是这个，因为在微软如果到特性组一级，你完全可以做一些自己决定，按照自己的做法做产品。只要你自己在技术方面能实现的话。

　　王东临：

　　比如说做文学创作，像现在写电视剧一样,集中几个人,要求多长时间写出几十集剧本，工厂式地生产电视剧，那就很难写出像《红楼梦》这样优秀的文学作品来。同样像很规范化的软件开发管理过程中，如何既保证它的质量，也能有很高的创造性产品出来？

　　杨永生：

　　第一给他做好的机会，另外微软你可以内部轮换，你有很多工作机会，如果你做得好你可以做别的事情，如果你真的有想法，并且得到别人的认同，你也可以开展项目，这种事情是有的。象Xbox，原来实际上是几个工程师闲暇时间做的东西，只要他能说服上面说这个东西确实有市场、有生命力，你就可以把这个想法变为一个产品。

　　提问：

　　刚才微软那位先生说，软件开发过程跟电影行业这是一个挺好的比喻，因为都涉及到人，但是人的能动性都在里面，但是软件开发过程中可能跟拍电影有些类似，有一些时候我们所谓的软件高手，好比我追求一种共性，追求一种工程化的东西，就要抹煞一些个性，因为每个人都有鲜明的个性就很难有共性了。怎么在开发过程中，特别像金山公司微软公司，在开放过程当中怎么把程序员，特别国内的程序员一般自视清高的现象特别严重，怎么把个性和公司整体，包括项目产品追求的共同利益结合起来，因为有的情况在产品过程中追求最大的共性，追求产品的特性，而必须要牺牲一部分人自认为非常好的想法，这是一种矛盾，而这种矛盾多了对公司本身也不是很好的事情，那么二者是怎么有机地调和的？

　　邹涛：

　　这种问题我们也经常碰到。你开始讲了大家都是很有个性的人走到一起来，事实上最后大家还是要慢慢的有一部分的共性，因为大家是在一起做事情，如果大家我说这样做，你说那样做，这样很难在一起合作，很难做出产品来。所以我们对程序员都有规范的要求，当然你可以有自己的想法，想法是想法，但是在编写的规范，或者其它流程方面你一定得遵守，你的想法可以用规范表达出来并不会规范规则，因为你产品涉及到不是说做完就扔在那儿不管的，它需要后期的维护或下一代版本的，所以它的可读性和可维护性是非常重要的问题。我们公司处理基本就是这样的，还是需要你个性稍微收敛一点点，融到共性当中去。如果你的想法特别新颖独特……

　　我还是没有搞清楚他的是想法还是行为？(回答：行为)行为又表现在他编程的行为还是为人个性的……这个不好说。编程行为肯定是协调一致的，你的想法实现的方法很奇妙，当然大家就用你这一套，这是不矛盾的。如果你这个人个性比较古怪，很难和人合作，这个我们基本上不会把他放到团队当中来。

　　提问：

　　项目经理他写出需求文档，他定出详细技术规范，这个技术规范会详细到什么程度？

　　邹涛：

　　我得说明一点，刚才杨先生说的我理解，我们这个公司是什么，项目经理写的并不是编程规范，编程规范是程序员日常编程的准则，项目经理写的是针对产品来说，根据用户需求分析，然后设计出功能点定的规范。假如你有一个窗口，点这个纽它会产生什么结果，是这个规范，而不是技术代码怎么写，这两个规范是完全不一样的。

　　杨永生：

　　产品说明规范比这个更详细一些，最简单的可能对话框什么样，最复杂的有些可能会涉及到可能用哪个函数去实现可能更合适一些，前提是把这个问题描述得特别清楚，开发人员看到了以后，可能会去设计算法，或者能去做，而不会反过来再问你。

　　提问：

　　说到算法，软件开发过程中，软件有两个大类，一种要求是技术，技术含量特别高，第二技术难度不是很大，但是需求特别大，软件工程概念是不是特别适合技术难度不是特别高，但是需求特别多特别复杂的需求。如果涉及到一个算法，像微软做的多媒体方面，比如这方面的编写，这种算法和这个过程来说是不是用到软件工程的概念？

　　周之英：

　　我想软件工程对于所有的软件来说，各种情况都是有用的。不光是对特别简单的。但是在一些比较复杂问题的时候，可能你不是那么容易得到一个机械的步骤直接就到底了。软件工程主要帮助你解决一些无效的工作，提高你的效率，并不是替代你的工作，就是把一些混乱的东西变成有条理。所以如果你有创意：有些人创意一会儿想到东，一会儿想到西，比如想到17、8遍，最后想出一个解决方案。如果你有软件工程的思想规律，可能你就会缩短这无效的搜索途径，你可能就会更直接地得到它，减少中间很多不需要、不必要的工作。应该从这角度来理解。不要把软件工程看成一个架在你头上的紧箍咒，这是你自己加的，何必呢？

　　我随便举一个例子，咱们国家大学里对学生的软件工程训练很少。这不光是中国的情况，现在国际上也在讨论，就是大学里面教了学生编程语言，但是没学习怎么达到工程化要求。有几个人和我一起工作，我规定他们两礼拜给我一次书面报告，简单说明做了哪几件事情。对报告中问题我可马上返回给他们。他们从电子邮件送来的文件，愿写什么名字就写什么。我觉得很麻烦，今天“DZI.doc”，明天“设计.doc”。单看机器的文件夹，我搞不清楚那个文件是早期的，那个是后来的、是谁的、是什么内容。我就要求每一个文件规定命名方式：姓加上内容性质，是小结就写小结，是设计写设计，是需求写需求，后面是日期，如果你这一天来了两份，第二篇再杠一杠二，这样就很清楚了。这就反映软件工程。他们头一天这么交来了，过了一礼拜又来了“DZI”了。这是什么呢？这不光是简化我的工作问题，而是简化你自己工作的问题，在自己机器中这一次报告跟另一次到底有什么差别，为什么我把你的报告退回去，自己可以有一个清晰的记录。这就是软件工程。软件工程的思想就是把你无效的劳动去掉它，一查，可以查到我想要的东西。所以种种规定要来帮助你，你说束缚了我的创造力，我的文章名非要写“DZI”，这何必呢？这么来看软件工程是什么，就有很多好东西来帮助你。至于是不是需要每一个文档都要规定：首先要写什么名词解释，第二是总体目标什么，这倒不一定，看你具体情况，有一些情况需要，有一些情况不需要。有很多东西，关键是你要掌握它的思想。它是要把你的无效劳动去掉，帮助你自己总结哪些是你的有效劳动，哪些是你的无效劳动，把这些东西弄清楚。

　　主持人潘加宇：

　　下一位主讲嘉宾是摩托罗拉全球电信解决方案部网络方案技术中心的高级经理胡大庆。摩托罗拉网络研发中心已经在2000年通过了CMM5的评估。CMM是目前国际上最实用的软件开发过程标准，和软件企业成熟度评估标准。目前我们国内一共有两家企业通过CMM的评估，两家都在摩托罗拉，另外一家摩托罗拉的中国软件中心。胡大庆先生毕业于清华大学，多年来一直在中国、日本和美国公司从事软件开发和管理工作，网上有一篇被大量转载的文章，文章题目叫做《实施CMM是一条没有终点的路》，胡先生在文章里面发表了许多精辟的见解。他今天发言的主题是《CMM与软件过程改进，需求管理及软件产品，质量保证》。现在有请胡大庆先生。

　　摩托罗拉网络方案技术中心高级经理胡大庆：

　　大家好。很高兴有这样机会，因为过去虽然都是中国人，都在海淀区，在中关村这一带，但是隔离还是比较大，交流机会很少，今后多增加这方面的交流。因为从任何意义上讲我们也是一个本地的公司，从国家信息产业部的文件规定，像我们公司的性质也应该纳入到国家软件行业管理的规范之内，从人员构成来讲，现在百分之百都是本地人或在国内受过教育。

　　我刚才也听了像周老师讲的观点,我非常赞成。我们在实施过程中是在2000年初，也请周老师给我们做过软件工程的课。现在经过不同的渠道，我们在第一线进行实践，周老师在理论上继续进行深入研究。但是我刚才听了一些观点非常一致，我也感觉有一些安心。

　　刚才大家的问题好象更多的是在企业管理和运营方面。今天也不是专门来讨论CMM，我只是把软件工程具体实现方法的其中一种可能选择CMM，这方面稍微谈一谈。

　　我觉得你是否选择CMM，或者有些企业已经用了ISO，或者其他的标准都是可以的，而且可行的，而且相应收到效果的。对于CMM，我希望大家应该有一个正确的认识，有一种看法应该纠正，我不是说在座，至少是社会上有很多人有这么一个想法，就是说比较简单把CMM作为一个认证，就像ISO这样，实际上CMM绝对不是一个认证，CMM它有五六个特征，它其中有一个可以作为认证的标准，但是现在我们过于突出了这一个特征了。所以如果你没有一个具体的按照CMM的框架，按照它的目标来实现，没有实践积累的情况下，单纯追求第几级是非常危险的是事情，有可能导致你企业原有正常的运行机制失败，因为CMM的引入有可能要求你做很大的改动，任何企业原有的一套制度方法是基于实践很有价值的，如果你把它轻易放弃，引入另外一套东西是非常危险的。所以我觉得CMM更多的要具体的实践，看是否符合你企业的需求，在一段时间之后，自然而然你可以把它作为一个手段去检验你目前达到的水平。

　　另外CMM确实不是尽善尽美也不是包罗万象，CMM从出来也不断版本更新，它还是代表了广泛的软件行业的共识。它是通过一些统计的规律显示出采用CMM后对企业带来的好处，或者如果我们对过程改善作出努力的话，CMM可以是一个比较有效的工具。就是说这工具是不是特别适合你，或者说你使用了工具肯定有效，这也没有任何人来保证。