第４７期ＩＴ沙龙 资深专家谈现代软件工程（续）

　　提问：

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

　　邹涛：

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

字串9

　　提问：

字串4

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

字串2

　　邹涛：

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

字串1

　　杨永生： 字串8

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

字串1

　　王东临：

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

　　杨永生：

字串2

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

　　王东临： 字串5

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

　　杨永生：

字串6

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

字串5

　　提问：

字串5

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

字串7

　　邹涛： 字串8

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

字串3

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

　　提问： 字串9

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

　　邹涛：

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

　　杨永生： 字串6

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

字串3

　　提问：

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

字串3

　　周之英：

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

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

　　主持人潘加宇： 字串4

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

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

字串4

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

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

字串9

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

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

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

　　另外还有一点，我觉得CMM核心有一个成熟度的级别，它之所以定位这样的级别，也是衡量你改善过程中你自己要知道你究竟处在什么位置，现在不应该把级别本身作为追求目标。应该是把采用CMM或者说改善和你企业最终的或者最初的业务目标紧密结合起来。比如说微软为什么不用CMM，从它的发展过程，现在的规模，或者企业的市场的形式决定了他们完全没有必要采用这种，但是不能说，微软没有采用CMM，CMM就没有用，这完全看你企业怎么想怎么做。

字串1

　　如果采用CMM的话，根据我们的经验，我也简单说一下。其实CMM很大的特点可以裁剪，就是说它给了一些不同的关键过程域即KPA，它同时可以说你企业有一个共同规定好的规范，并不是所有项目都要遵循一套规范，因为不同项目周期规模都不一样，它采用生命周期都不一样，你不可能要求所有公司都要用同一套规范，所以你可以裁剪。任何规范毕竟不可能是非常完善的，所以大家反过来不能对软件工程，尤其对具体方法有这么苛刻的要求。

　　另外在实施过程中，大家应该根据企业的需求，在小的范围内，从低的级别来做起，而不应该是大张旗鼓动的太厉害。因为CMM本身的几个级别也是根据多年考虑，工业界的反馈和意见，大家认可的，认为先做哪些，做到了二级，如果完善比较好的，把具体经验再推广到整个企业和各部门中，然后再加一些调整就到了三级，四级就更进一步实践中加上一些更多的定量的数据分析，还有一些东西，可能要求更高一点。

　　所以它要求的是一些比较小的，在你已经做得很好的基础上，按照CMM决规划来做小的改善，而不是有一个巨大的变化来取代原有的一切，这是它的一个特点。

字串8

　　当然它也需要如果参加的话，应该大家都有一个共同目标，要积极参与，同时对所参与的人员都要给予相应充分的培训，对企业来讲，关键要考虑到你的投入，因为软件投入主要是人员，而人员主要投入是时间，如果没有任何投入，你就奢望有一套新的制度能引进同时促进你企业有一些变化，这是不可能的。

字串9

　　在实施过程中还应该加一些比较有效高的工具来帮你实现，比如说它其中有一个SCM，就是配置管理，这必须依靠工具，因为你不可能靠手工对版本进行方便有效的管理。 字串1

　　第二个问题，我看到大家有一些观点，把需求的管理和最终推向市场的产品好象割裂来开，甚至处于一种矛盾之中，就认为需求有什么用，或者需求没有必要做的很详细，只要最终能够满足客户的要求。其实我觉得这本身就不是矛盾，因为就我个人来理解，所谓需求管理就是主要包含需求的定义，以及对需求变更的控制。需求定义应该建立在与客户，当然有一些做商业产品不是只对直接用户，就是针对市场，在充分交流基础上来反映出需求，这是它的定义。定义好之后，一系列的设计、技术、文档、编码都是按这个来做。需求的变更完全需要遵循一套已经定义好的过程来做。而不是说非常任意的或者是随意的来进行变更。因为我们最终不希望，把需求文档当成摆设，导致需求有什么用的疑问，正因为你对需求变更没有做控制，因为需求应该随时反映出你和客户双方的认可，对需求最新的变化，而这里应该说双方认可，而不是说只要客户要求变化了你就必须变。这个大家要注意，一定双方要进行真正沟通之后，因为有时候客户要求是没有道理的或者是不切实可行的，明知道你做不出来，如果无条件答应,那么最终结果可以想象。 字串9

　　另外从需求开始一直到最后，我觉得整个过程应该有一个非常严格的叫做可溯性的管理，英文叫Traceability，就要一直可以不断地检查，他要求你做的每一件事情都是前一阶段都定义好的，而不是需求只是需求，分析是分析，等到设计时我已经走变样了，因为客户来了新的要求,我需求不管了。那么设计出来的到编码过了一段时间又变了，所以这样的话，那确实需求就是一个死的摆设。我想正是因为这样，刚才周老师讲了，虽然软件工程确实对一般性可能不太好管，但是对这么具体的东西定义的还是比较清楚，对企业是非常有帮助的。这也是对我需求管理想到的一些。 字串9

　　还有一个观点，我看议题中多处老是把文档和代码对立起来谈，分开谈，至少我不是这么认为，它们都可以统统纳入到软件的产品，软件产品应该是一个比较广泛的概念，它即包括最终交付给用户的，你可以交付原代码，交付用户手册，其实在整个开发过程中，你所相应产生的任何附带的产品或者阶段性的产品，包括你开始的相应的计划，你的需求的分析，技术文档，测试报告等等这些都是产品，当然这种产品未必是最终交付给用户，但也算是产品。所以应该正确认识到它们都是软件的产品，而不是只是源代码是产品，这样容易造成代码和文档之间，对立的关系，老是这样会走到偏激的地方，我觉得软件产品是一个有机的整体，它只是不同的表现方式。

字串7

　　最后我谈一下质量保证的问题。因为我也看到，有一个观点或者叫是事实还是原则，就是说满足市场才是第一位，代码的质量好象不是特别重要，这不是原话，这本身就是矛盾，不应该将市场需求和产品质量对立起来。什么叫市场需求？它其中核心部分就应该是产品质量，因为任何市场需求最终还是一种个体的一种客户的需求，你要占领市场，你要满足用户，同时你应该想保住它，希望他买下一个版本或者买你新产品，你应该有质量高的产品吸引和保住客户，因为人们不愿意使用他已经知道的有缺陷的产品，所以不应该把市场和用户的需求和产品质量剥离开来谈。

字串9

　　产品的质量，我想应该说包含一些要素，比如说它包含质量的控制，质量控制从具体实现方法就是测试，像微软比较成功的就是无论是人员的配备，还是部门角色划分的区分都是测试比较严，它可以通过大量的方法可以把产品的缺陷及时地尽早地发现，并且加以解决。这是非常行之有效的。现在国内企业有认识到这一点，从没有测试部门到增加测试部门，当然比例不是很高，这测试部门不一定在行政上独立，但是角色一定要独立，绝对不要开发人员自己测试自己东西，这样效果不会很好。

字串1

　　另外从CMM角色来讲，质量的确保，它希望同时定义良好的方法，能够在整个开发过程中来实施这样一套过程和方法，从而保证你本身开发过程中产生的缺陷就比较少，这和质量控制还有一定的区别，质量确保是希望能够利用好的方法来保证出来的产品本身就比较少的缺陷，因为零缺陷不可能。这样反过来讲，你再通过测试的努力，应该说会少一点。因为测试虽然很好，但是大家要知道，如果你在系统测试或者比较靠后阶段发现的问题，如果它是在设计或者是需求或者编码引入的话，重复的劳动是非常大的。一个开发的组织如果这种重复劳动大的话，它的成本就上去了，我们的市场竞争力就在这儿，因为你最终产品定价可能市场已经决定了，你怎么把你的利润提高呢？那它决定你的效率高，你的重复劳动成本降低。这是我对质量的认识的两个方面。 字串2

　　提问：

字串2

　　有两个问题，第一个你曾经说到从需求开始一直到产品的推出，有一个可溯性的管理，这中间的一致性怎么保证。第二个问题，如果后期犯了错误，如果在开发初期就已经埋下祸根，如果避免开发初期的设计上的错误？

　　胡大庆：

字串4

　　我先回答第二个问题，质量确保就是用来解决这个问题的，它通过正确的方法，比如CMM规定同级评审，他对你做出的文档，对代码阶段性成果都要通过一种方式来进行评估，通过这样工作就可以把本阶段，或者把本阶段以前的错误发现出来，而不要带到下一阶段，这样就保证错误尽可能提早发现出来，错误越早发现出来，给你带来的重复的劳动工作量就越小。应该说质量确保这样机制和方法的引入可以适当的保证你不应该把更多的缺陷带到后面的阶段。

　　第一个问题关于可溯性，当然企业具体的做法不一定一致。比如说可以用一些工具，包括微软也可以提供一些工具，其他专门软件工程公司提供的工具，你版本的管理，从你项目计划开始，到分析、设计，到原代码的管理就是保持一致，就是目前你所做的设计你依据的是哪一个版本的需求，你下一代的原代码是不是依据这个需求，这有一个良好的跟踪观察的强有力的保证方法，还有靠制度和使用人员基本概念要培训，让大家都知道，你是在用好的方法做事情。另外还有一点比较重要，就是说这个概念国内大家也逐渐认识到这个问题，任何原代码即使你认为原代码很重要，大家应该教育工程师，你写完原代码，经过一个阶段，提交到一个地方之后，这个东西就不是你的了，不是说只要是你写的，就是你的，你随时可以拿出来，你想改就改，这就错了。如果是这样，你慢慢就会有一些错误发生，这样就不会知道谁是最好的，谁的设计和现代的是一致的，这样你把这种制度或者过程建立起来，而且教育员工一旦提交之后，这就是项目组的共同产品，然后再进行怎么修改，然后再怎么做。

　　提问： 字串5

　　您刚才讲到质量保证，你是依靠一整套质量体系保证产品质量，我听一些朋友说，他们在小型的团队中他们应用的不是完整的质量体系，他们可能用XP(英文)的方法，满足客户的需求，以后出现问题时，我肯定有办法把它重构好，你说的完整质量体系对小公司是不是也实用，因为他更需要的快速的反应。

　　胡大庆：

字串1

　　我觉得有一个特点，虽然理论上说一个人做软件也要引入软件工程，但是人多和人少做软件还是不一样，我觉得一个五个人十个人做，十年五年都想保持这个，你可以这样。如果你想扩大你的软件企业的规模，我想你们就不一定能满足你企业继续发展的需要。如果你的市场是某个校园里的大学生，他每个礼拜都让你出新东西，你没有必须保证质量，如果你满足这个小的需求就可以了。但是我们从我经验来讲，我们的软件比如中国移动它有上百万的用户，我不能奢望它能原谅我质量方面的任何缺陷。所以确实在不同规模，不同市场的需求下，质量的要求或者做法，或者这方面投入也是不太一样的。就是说在这个阶段你不可能百分之百解决好的方法，因为你没有这么大投入.但是你把软件工程的思想引入到你的公司里面对你下一步发展是很好的。否则你发展到一百人的那一天你再想让大家改过来这个习惯就很难了。

字串8

　　提问： 字串2

　　摩托罗拉是用6个西格玛了，你能解释一下？

　　回答：

字串5

　　摩托罗拉更主要的产品是大的机站，所以6个西格玛是追求整个系统产品的质量，我讲了CMM也不是十全十美，它对后面客户服务业没有涵盖住，在我们所在的部门也要用很多东西来弥补，因为我们有一个不太大的硬件开发队伍，还有系统上测试的东西，这些过程不能用CMM来涵盖，有人讲CMM全面质量控制管理在软件上的实现，对我们来讲6个西格玛对这个并不是矛盾，它应该相辅相成的有一些帮助。 字串7

　　提问：

字串6

　　大家都知道软件工程主要消除个人因素的影响，但是我觉得每个人的一些特点也是需要的，在微软和摩托罗拉当中对具体个人素质有什么要求。我知道CMM有TSP和PSP。

　　胡大庆： 字串1

　　我们百分之百的员工在大学阶段都是在国内受的教育，我们的比例当中也有一些博士也有一些硕士。我觉得更多的是摩托罗拉做的比较好的一点，就是公司里的再教育，或者叫做ON-Job Training，这确实至少在国内外企里做的相当不错。它把一些过于理论的东西根据企业的要求进一步广泛的培训。所以我刚才讲全参与全培训，你希望他做这样的事情的人你却没有跟他讲清楚，你不可能奢望他有一个好的结果，因为本身人的惰性就很大。某种意义上就有点像公司的规章制度一样，我要求你这样做，不是可商量的。比如像项目管理，经理要求你开什么样的会，参加什么样的活动，出什么样报告这都是有严格要求的。但是这个是不是抹煞了个人的创造性，其实不是。反过来节省了你一些不必要的浪费，时间的精力，可以把更多的精力放在让你发明创造这方面。 字串4

　　提问： 字串1

　　软件质量有一个前提，如果对软件规模没有估算，我觉得可能会导致计划进度安排不太准确，可能达不到目的？

字串3

　　胡大庆： 字串9

　　在需求分析阶段也会写一些方法来付出，但是没有绝对一个方法保证你百分之百正确，比如你整体交付原代码的估算是多少，这个我想更多的是经验是非常重要的，或者更多的如果你原来有类似的项目做过，这都是一些依据，另外你把你的需求尽可能细化，细化到以周为单位的工作量，就是尽可能细化，这样比较准确估算出你最终用多少人多长时间，但这也是一个计划。我觉得CMM一个比较大的特点，我们的计划按照一定的要求是不断地在更改的，因为一年前定的计划明知道它不实用了，还为什么要留着它呢？但计划的修改还要得到一些人的认可。只有有针对性的，确实能指导你的计划或者需求才有继续往下做的意义，否则慢慢就扔掉了，没人看了。但是如果没有一个东西指导你，你凭脑子来想编程，你越往后你就会发现你绝对要失控的，因为我们在谈向规模化的企业。 字串4

　　杨永生：

字串2

　　我同意胡先生的观点。规模小的时候你可以容易控制。所以将大的项目分解有助于进度控制。反过来要根据开发人员对日程的安排来做出最终的解释，很大程度上还根据实际经验。另外你永远要加一些冗余，就是做一个实际的估算。还有作为PM时你要做一些取舍，到关键时候可能要砍掉一些东西，或者增加一些东西，主要是取决于你发布时期是不是能改变的。 字串7

　　提问： 字串1

　　你说主要由开发人员来决定议事日程，这会不会导致产品开发时间的延长？ 字串4

　　胡大庆： 字串1

　　还有一个大的框架，就是让开发人员来作主或者参与并不是让他做决定，同样的产品他知道大概花多长时间，如果全部由上面人来决定，你没有反映到底下，或者是上面完全压下来的，开发人员即使知道做不完他也不说，如果这样对公司也是不好的。所以在这个意义上，也是在这个基础上的。

　　提问：

字串2

　　您讲一下代码的复审问题？ 字串3

　　杨永生：

字串6

　　代码的复审没有固定的过程，就是往往经验丰富的人开做。主要是在最后稳定化阶段，对于新的改动都要复审。至于特性规范说明，测试人员、开发人员、项目经理都会看得到，而且都会详细的看完，或者给一些反馈。项目经理之间，也会相互审核一下。

字串6

　　提问：

字串8

　　微软的开发方法，自《微软的秘密》之后有什么新的发展？ 字串7

　　杨永生： 字串4

　　从产品开发过程来看还是那样，无非是角色的一些变动，基本原则并没有大的变化。

字串3

　　提问：

　　从您讲的微软的岗位设置来看，您认为中国在这些人员中最缺乏是人员是哪些？您认为怎样去解决？

　　杨永生：我们最缺乏什么样的人员，我想在座的每个人，听了我的介绍后，自己回答这个问题更好一些。 字串8

　　提问：

字串8

　　刚才胡先生讲软件开发过程，所有文档都作为产品来看待，我不知道摩托罗拉对除了代码以后文档把它作为产品有没有一个规格？ 字串1

　　胡大庆： 字串9

　　有，当然这个经验是不是可取，是不是大家都使用这是另外一回事。但我们做法基本上你要形成文档或者阶段性东西都是有定义的，都是有样本。比如公司要求你按照什么格式来写，通过什么样方式在一定范围内做一个评估之后，才能最终确定下来它是要继续执行来用的。我说得过程中的产品，一些东西，并不是说你在A4纸上写了三行就算文档保存了，还是要稍微正规一点的东西。没有必要把文档都非常机械，非常像写论文那样来写，也没有那样的精力，但是你基本的要素，基本的东西还是要交代清楚，否则你就没有参考或者进一步利用的价值，因为每个东西既然是产品了，它对你下一阶段或者某些工作是有帮助的。 字串3

　　主持人潘加宇： 字串3

　　我们最后一位主讲嘉宾是北京世纪豪杰计算机技术有限公司梁肇新总裁，大家都知道超级解霸软件是很有名的软件。我们知道软件最终要生成代码，代码质量往往决定了软件的质量，作为成功的程序员梁总可能有许多宝贵的经验。他今天发言的主题是《代码规范化》。有请梁肇新先生。北京世纪豪杰计算机技术有限公司总裁梁肇新： 字串8

　　我主要讲一些比较实际的东西，因为我们公司不是很大。我们98年成立到现在碰到了很多问题，在这些问题解决过程中，我总结出来代码规范化非常重要，因为从教科书上就没有一种规范化的提法。我发现很多开发人员最后写出来的代码都不相同，这样的话写出来代码就成了他自己能看，别人不能看，这样很不好。刚才讲到CMM里面，我想每个公司可能都有自己的规范，我就讲我们自己的代码规范。 字串6

　　代码可能有价值的，但是如果一个代码没有思想，就纯粹是乱码，是没有任何价值的。所以代码分两种，要使得代码有价值，它可能要规范化，要有比较强劲的设计思想，代码本身要有思想，这样代码才有意义。以前包括有一些人到公司推销代码，我们一般不会理睬这种事情，因为他代码可能跟我们实际有很大的差距。所以怎么使得开发的思想统一，使得一个团队里面的行为能够一致。 字串6

　　我们实际的做法第一件事就是到我们公司的人员首先做代码规范化，我们做法是开发语言的统一，我们做一个相同软件不可能说一个用DELPHI，一个用VC，每个人写的都不相同，所以我们统一成用VC来开发，然后我们再要求格式，格式分为层次，就代码的格式层次一定要清晰。我们区分代码时用“TAB”，教科书里往往看到大括号不对应，很多“FOR”以后往往一行都是大括号，最后有一个解决办法就是在每一个括号后面写上是哪个括号的。

　　在处理代码，我们自己写代码的时候，我不知道现在开发人员怎么写，但是我们自己总结出来以后，我发现要写一个文件时要先把它主干提出来，然后再给它填枝叶，那怎么写呢？我们进行了成对编码，先写上面大括号，再写下大括号，然后再加中间的，因为我们实际在以前做过的过程中发现很多代码最后分配了很多内存，没有地方去释放它，最后机器自然被消耗，程序就死掉了，所以成对编码我认为就比较重要。

字串3

　　小一点程序在环境里面就自己生成，把它拼凑成一块就把它拿走，我认为这种方式不是很好，应该把它建立成BUILD，把所有文件放在一起写成TXT文件，然后就输入BUILD命令，它就能把你所有你要的东西相通的。 字串4

　　我们实际发现使用过程中用CVS做为代码管理比较不错，CVS能解决两个人同时写一个文件时怎么办的问题，绝对不是说我在编这个文件别人不能编，在同一个文件里头，也可以解决，两个人可以在同一个文件里写。这个CVS可以直接把这两个部分合并成一个文件，解决同时编码冲突的问题。

　　还有一些开发理念的习惯，我们觉得比如像代码在教科书里面比较多的，还有实验性代码比较多的与assert有关联，我们实际使用中不要用这个东西，因为这个最后推出产品的时候，有两种方法，一种可能根本把这一行去掉，另外一种运行时会出错，弹出一个对话框，如果你怀疑这个地方有问题，就应该有一个相应的处理方法在这个地方，就不要使用assert来取代它。 字串5

　　我们早期版本用过一些MFC的程序，后来我们发现错误很多，现在就不用了，MFC可以产生很多废码，看起来效率很快，但是问题很多。我们宁愿慢一点，但是要很多东西都可靠，这些代码可运行性很高。在代码实际中分层次编码是非常重要的，在每个行数前面一定要有一个统一格式的注释，你代码里面没一个注释也是很重要，但是每个函数前面有一个比较完整的注释，别人看这个代码时就像这个东西是我写的。这样使得这个团队有一个比较好的协作基础。 字串9

　　主持人潘加宇： 字串2

　　谢谢梁总的精采发言。

字串9

　　提问： 字串9

　　我想请问一下梁总对代码的重构有什么看法没有？它是指一开始的时候就比较快，还是比较规范的很快写出一些代码来，不考虑以后的需求变化，等到以后需求发生变化时再去给它想办法重整这个代码，在它不影响它的功能的情况下？

字串8

　　梁肇新： 字串8

　　我们使用动态库设计这些东西，在设计整个软件的时候，我们也有一些开发人员不了解这个开发性，代码写得比较封闭，一个程序用一个大类来实现，最后给这个东西添加功能时非常困难，所以我们就要求实际开发过程中尽量把所有东西能提出来放在动态库，以免将来改变时的麻烦，再不需要对动态库进行改变，你只要在需要改变的地方进行测试就可以了。 字串9

　　提问：

　　您以前是个很成功的程序员了，成立自己公司以后从开发第一线退出来，从第一线到开发人员这需要在思想上有什么样的转型。您对软件工程方面是什么见解？感觉到自己公司在软件工程上需要有什么帮助？梁肇新： 字串6

　　我们公司现在规模还比较小，我们最困惑的是2000年的时候，当时我们团队刚刚建立起来，为什么我们会建立代码规范化，也是因为实际中代码混乱，所以我们在实践中建立起来。年底的时候我们听说CMM，我们去请一些老师过来实际培训了一下，使我们视野开拓了一些，但是实际上还是按照自己实际需求。朝这个方向做是很有必要的，但是做的过程中我们是很谨慎的，不会把原来东西打乱了，我们主要目的是使我们开发更加可管一些，更加规范化一些。我自己一直定位为程序员，就是开发人员，而且我本身就喜欢编程，我觉得编程就是一种娱乐，而不是一种工作，我一直在做实际编码工作，所谓代码规范也是我实际使用中发现它有很多好处，然后再总结出来的。 字串8

　　提问：

　　您怎么处理编程的身份和总经理身份的？

　　梁肇新：

字串5

　　像我们公司技术方面我主要负责这方面，还有产品，如果要决定什么样的东西，比如2000年网络很火的时候，市场人员要求我们是不是也搞网站搞风险投资，我觉得这跟我们定位于软件企业根本不同，这两个相当于跨行的，所以这东西不是我们要做的，所以最终我们还没有做这方面的工作。我主要是做技术，在技术的前瞻性，看哪项技术能运用到哪些产品里面去，目前最新技术是什么，这些技术我们拿过来以后，我们能做什么样的产品，我主要考虑这些东西。而实际中我会做一些比较先进的底层的技术，做好后提供给实际项目中使用。 字串5

　　提问：

　　您是作为程序高手或者程序英雄，我非常好奇，如果您总是编程，您不可能管理好一个团队，你可能抽出时间进行管理，您怎样处理编程和管理这两件事情？ 字串4

　　梁肇新： 字串8

　　管理不是我的长项，我们工作的日常管理和其他管理有其他人做，我就相当于技术骨干的角色。 字串4

　　提问： 字串4

　　我问一个问题。我接触了很多出版界的朋友，我发现国外软件工程软件管理在知识资源上非常丰富，但是国内比较少。那我想问一下，大家也是在实践中去带团队，也要鼓励自己团队中成员去成长。从知识角度来说，就看他们有什么样的素质，我希望嘉宾从个人体会来说，如果您希望您团队成长的话，从知识角度怎么样来配合？ 字串5

　　周之英： 字串7

　　我想这个问题从我们国家来说，应该从教育和工业界共同努力来解决这个问题，某种意义上，国际上包括美国也在重新认识这个问题。从总体来说，软件工程是超越一个具体项目，但是很多人现在并没有把软件工程中间那些思想本质的东西掌握到，而是把它当成很简单的理解：一个规范，我照猫画虎就能做了。

字串9

　　我教软件工程课也碰到这样的矛盾。有人总说周老师你教的东西太抽象了，我也学不了那么多，只要给我一个样本就行；我要做可行性报告，有没有东西给我抄一份。这很典型。当然这个情况可能特殊点，但是对大多数人也一些影响，程度不同而已，就没有把它作为很重要的、发展软件工业的基础来看。软件工程里面有不同的层次。

　　国外这方面开展研究很多。我们国家一开始就有一个误区，就是从80年代初开始搞软件工程的时候，认为软件工程一个是规范，第二个是中国开发出自己的工具来就行了，看成非常死的东西。考虑一个规范，好像什么东西也不需要，就可以照着做、就能解决问题了。第二个误区，只要开发出一个东西，然后这个东西就能解决一切的问题。实际发展的二十年来，不断地探索，人做软件的一些规律性的东西，包括技术的东西。里面有各种不同的层次，包括编码，需求分析，开发，发展新技术，有很多层次。我觉得今后教育方面有很多工作，比如现在的大学教育中，就像编程问题，没有一个教科书里写工业产品的编程是怎么编的，学的编程课程是学语言，就把语言弄懂了，这是面向对象的语言，这是结构化的语言，是学语言而不是学做工业化的东西。

　　其他层次的都是需要很深层次。我有时候也很困惑。有人跟我说：我对软件一点不懂，我现在要搞一个软件项目，你告诉我我怎么去管。我想如果要建造一个房子，没有一个人会对建筑系的教授说：我明天要设计摩天大楼了，我对建筑什么也没学过，请你告诉我用什么办法，我明天投标去。但是你看软件就有这样的状况。当然软件也有它方便的地方，现在技术使一些软件很容易编，但是你要做到不同层次的话，就有很多深层次的问题。 字串8

　　所以我觉得一个从工业界怎么不断总结，一个从教育界怎么能够改变过去仅关心计算机科学技术，也去关心软件工程的问题。以后可能对我们国家的长远发展会有一个比较深刻的改变。 字串6

　　主持人潘加宇： 字串6

　　今天到现场的还有一位，大家知道国内软件工具有一个叫做“PLAYCASE”，这是一名叫高展的先生基本上是他一个人开发出来的，因为国内软件工程大家是谈的多，做的少，软件工具方面像青鸟开发了一整套，但是一般公司一般人都见不着，不知道用在什么地方，但是像高展先生，他一个人踏踏实实地把“PLAYCASE”写出来了。下面请高展先生说怎么把“PLAYCASE”写出来的。

　　高展：

字串9

　　书生公司王东临先生提了一堆问题，我从两个角度归纳了一下，更容易回答书生公司提出大概几十条的问题。这两二个问题第一个问题是软件工程实践者的观念问题，主要是中国的软件工程实践者，再一个软件工程方面自己的原理上是不是也有问题。 字串2

　　首先我们中国软件工程实践者自己的观念问题，我前一段时间曾经发表过一篇文章，说中国软件公司是没管理没技术，大家可能不赞成这个观点，实际上现实情况是这样。软件工程就两大因素，一个是软件开发技术本身，像怎么做需求，怎么做编码；再一个管理问题，再一个看软件开发管理上。因为软件开发主体基本上是软件公司，公司非常明显的特色就是分工特别清晰，分工问题是在230年就提到这个问题了，我们的软件公司在去年的时候才提出，这个结论是百分之百的正确，所以我们软件公司观念落后了230年了。今年就不同了，有专门的部门了。再一个软件管理水平的确管理很差，就是量化管理。在传统行业上，我们整个管理水平也是落后大概一百年左右的水平。因为在二十世纪初的时候，有人把一个建筑工人在弯身、拿砖头、抹灰这三个动作进行分解，然后再进行测量，最后实行了精确管理。我们国内一般企业都做不了这个管理，不用说软化公司了。所以软件公司整体开发水平并不是特别乐观的，这主要是观念问题，这方面大专院所也做的也不是特别理想。所以这方面可能从观念上这方面问题更研究。就是大家首先认为需求不可能做透，好不容易认清楚了做了“coding”。 字串3

　　所以整个软件开发从生命周期来讲，我们每个阶段都在犯错误，所以我个人理解，我们现在软件开发，做管理软件来说在于需求，需求关键在于哪儿？我个人认为对于用户本身业务的建设，这问题最大。所以这里面里头涉及到软件工程原理的问题，从我个人从软件来讲，我应该是后外行，我不是学软件出身的。 字串8

　　我大概在89年90年接触软件工程。我们当时学，老半天很不容易学懂，发现很难为用，我们从书上，从国内外书上看做需求分析的方法，太难在工程当中进行操作使用，所以最后我总结出来，可能是软件工程这门书上对如何做需求分析给教错了，做设计做其他的可能都没有问题。现在最大的在源头可能有问题，因为软件开发源头被污染了，下流再怎么治理可能一点意义都没有。所以我个人认为软件开发可能是一个赝品的概念，就照葫芦画瓢，这瓢就是软件，这葫芦就是应用领域，企业的管理模式，从根本上解决需求分析做的步骤，可能首先把依靠用户对领域的问题解决掉。这方面我们做的还是有一些成果的。我们提出来一个观点，全程一体化……就是对用户领域的分析，做需求分析，然后做概念设计再做总结设计，这样就会很顺畅。这样某种意义上消除了软件总体设计时间，包括详细设计时间也会消除到60到70%的时间。 字串2

　　这都是我个人的观点，一个感觉是本身中国软件工程的这些实践者观念有极大的问题，现在虽然这些问题在逐渐消灭掉，不过消灭也有很大问题，我大概在97年98年的时候，是我在跟软件公司在讲软件工程的重要性，到99年这些软件公司的总经理在给我讲软件工程给我们带来什么好处。我现在感到感觉最大的难处是如何说服具体开发人员认识软件工程的重要性，我现在做了很多培训工作，绝大部分都是总经理技术总监，包括部门经理来推动这件事情，唯一遇到一个案例就是员工做这件事情，总经理不愿意干，可能怕花钱，员工学会了会干别的事情。这是观念问题。至于你采取什么方法来做，这都是无所谓，主要是观念问题，大家认为软件开发能不能按流水线方式来做，这是最重要的。

　　提问： 字串7

　　全程建模我以前也用过，这有一个问题，这是一个普遍的问题。这是关于UML的，在你的软件里面我也用过UML，在使用的UML和面向对象的时候你是怎么实现的？UML在整个软件工程里面它起到什么作用，主要在设计上面的作用？

字串4

　　高展： 字串7

　　用我们一体化如何来体现UML方式，我们做了一些工作，就是我们把面向对象和结构化这两个做了一个综合，所以实际上我们兼容了大部分UML，包括它的顺序图，包括对象图，这是比较主要的，在我们这里都会得到体现。它的图形语言我感觉我们大概兼容了80%，就是一一对应的方式。

字串1

　　包括对象应用，跟结构化没有区别。这个结构化对象分解本身就是结构问题，就是对象组成关系本身就是结构问题，所以这两个完全没有区别。 字串6

　　提问：

字串8

　　因为我在用你的Playcase建模的时候，我发现还是以模块化为主，就是面向对象很难加进去，实际上我们软件公司要求软件编码的复用要求程度很高的，所以我觉得你在这方面有一些缺陷或者不足。

　　高展： 字串5

　　这应该看办法和工具，从办法学角度来讲我们是没问题的，如果你用纸和笔来肯定不会出现这个问题，可能我们工具在这方面有一些问题。

字串5

　　还有一点我稍微解释一下，关于模块和对象的问题，我个人的理解，软件工程所有的追求目标就是模块化，所以实现模块化的手段构建对象都大同小异，包括用结构来描述，这是我个人的观点。 字串8

　　周之英： 字串5

　　关于结构化，我想软件工程的最根本的问题，最主要的就是控制复杂性。你的规模大、特别复杂，整个问题很复杂，所以要分解。不管怎么样都是用一种分解的方法，就是把大的问题变成小的问题来分别考虑，考虑它们之间的关系。可以有不同的出发点。从这个意义上，对象之间的关系也是一种结构，只不过这种结构看你怎么理解。过去的结构化方法主要是指模块调用图这个结构。从更深层次，我觉得现在的结构化还解决不了一些复杂的问题。具体说起来，就是现在提出的非功能性需求，比方说性能问题，安全问题。这些问题为什么不能够解决？按照目前来看没办法分解到某个模块当中，就变成非常困难的问题。现在如果处理单纯功能分解，某种意义上不复杂。用现在的工具来开发一些管理软件或者什么，有时可以不复杂，因为编程语言很高级，很快就可以学会。需求功能划分后，大家一起完成。但是你考虑一致性、安全、再加上黑客攻不攻、性能要快，各式各样的问题加进去，就复杂了。所以要用各式各样办法去解决。

字串4

　　还有UML，我想它是很好地刻画了面向对象的东西，由OMG组织的一大群专家的工作成果，跟CMM也是差不多类似、这种规模。考虑了各方面提出的各种需求，比方说package包装的要求，各种部件之间接口的关系会产生什么样的需求。所以从本质上非常丰富，可以刻画很多东西，是很好的描述手段。但是描述手段并不等于你能够解决问题，因为你要建什么模型还是要靠人去解的。并不是说UML来了以后我就行了。它只是代表现在很多领域提出的问题，它怎么来表达。最基本的，还是表达对象的一些关系：相关关系，继承关系，这是最本质的东西，也就是UML最早的那点东西是最基本的。假如你要更丰富一些，比如大系统、控制很细，你就可以把很细节的东西去描述起来，描述细了也带来一个问题，你描述越清楚，信息量就越多，主要问题就不突出，可能带来了其他方面的问题。所以不要觉得很丰富就一定很好，你也得要根据你的问题重点去选择。

字串2

　　第二个就是，有了UML并不是说你可以睡觉，就可以解决问题了。根据问题的复杂性去建模，这是根本的。这是一个语言。 字串8

字串1