|
【声明】如需要复制、传播本文，请附上本声明。谢谢！ |
||
|
[CMM] |
||
|
[M] 你在项目中采用CMM管理有多长时间了？对CMM的印象如何？从开始接触到目前为止对其认识是否有变化呢？ |
||
|
[L] 对于CMM整套体系我还不是很熟悉，而且我们公司在做CMM的规范时我的项目正紧，因此也没有时间参与其中。总的来说，我们公司是在最近刚刚启动的几个项目中采用CMM管理的，我手头的这个项目还没有正式开始，我估计正式开始后也会采用CMM管理。所以我从未使用CMM管理过项目。对CMM总的印象就是项目过程文档化，一个项目结束可能需要产生40、50个文档，而且这种管理模式对于比较大的项目应该是很有用的，但是对于小项目好像用不上，但是我想或许应该从小项目来实践吧。 |
||
|
[M] 在前面的谈话中，你曾提到“CMM中强调大家的整体参与”，从实际角度出发，你是如何理解这一点的？在公司规模不同的情况下，这种“强调”又是如何具体体现的？ |
||
|
[L] 或许在CMM中没有涉及到“CMM中强调大家的整体参与”这句话，这只是我个人的一点意见而已。因为在CMM中追求项目结果文档化，因此项目文档是一个比较大的工作量。我们公司一个项目结束后可能要产生50多个文件，如此大的文档工作量，如果让一人完成可能不太现实，而且文档的维护也是很大的工作量。因此需要把概要设计，详细设计等工作的一部分交给各程序员做，因此也就做到了大家参与。而且对于系统采用的技术，某个模块的具体流程等每个人肯定有每个人的想法，因此需要集思广益，大家参与讨论。无论公司规模的大小，比如微软，可能整体的大架构程序员不能参与，但是具体到小模块时，程序员就会参与其中。对这一点我的体会就在于概要设计和详细设计上，前提是大家都深入了解了需求，然后每人负责一部分模块的设计以及coding、文档的工作。 |
||
|
[M] 是否可以这样认为，在小规模的team中，程序员该主动参与框架结构的设计等整体设计工作。而对于大型的软件开发公司（比如微软）而言，这种方式是否不适合呢？在CMM中是否对此有所提及。 |
||
|
[L] 我的一点想法，在CMM或者公司中都没有具体谈到这个问题。确实象我们公司做的一般都是针对性很强的项目，所以在项目过程中大家都有自己的看法、自己的设想，而且项目经理或者所谓的系统分析员也未必就是考虑得十全十美。所以我的想法就是大家一起开会讨论研究整体的系统框架等问题，这样就能够集思广益。对于项目中的难点，关键的地方，大家都有个比较清醒的认识，也利于大家团结一心。我觉得即使在微软，他们也会或多或少地参与，他们也会提出他们的建议。好，这个问题留待讨论，实践。 |
||
|
[M] 为什么CMM管理模式对小项目可能不适合呢？CMM在国内的实施过程中，有人提到了裁减问题。对此你是怎么看的。 |
||
|
[L] 其实这个问题怎么回答呢！因为我对CMM不是很了解，我觉得企业在实施CMM的过程中不能全部照搬，如果全部照搬肯定不会适合自己的企业而且也会造成浪费的。我觉得我们公司的CMM执行就是，大家在一起学习一些CMM的思想，一起根据CMM的规则、流程制定一些适合公司自己的CMM的规则，公司按照制定的规则做事情。然后让CMM的评估机构来验证，看公司的事情是否是按照CMM的规则做的。这是我个人的感觉，因为我也没有参加CMM的培训、公司流程的制定，所以我也不是很清楚，只能按照个人的一些想法来回答你的问题了。 |
||
|
[M] 那你从一个公司普通职员的角度来看，这种“localize”的CMM制度，在公司内部的实施效果如何呢？ |
||
|
[L] 应该说localize的制度是符合公司的实际情况的，是根据公司的实际需要来做的。在实施的效果上应该是比照抄照搬的效果好一些的。但是CMM毕竟是一个很费精力和时间的东西，况且公司现在刚刚实施，因此大家难免会有做得不好的地方，或者抵触的情绪。不过相信随着时间的推移，随着大家意识的提高，应该会做得越来越好的。 |
||
|
[M] 对于一项制度，在其真正实施的过程中，总会有走样的可能。比如，你所在的公司在项目管理方面所推出的一些制度。对此，你有何看法。 |
||
|
[L] 我觉得制度是死的，人是活的。我们可能不需要完全按照制度执行，但是关键点应该保证。对于特定的项目可能制定的制度并不完全适合，所以我们要摘取恰当的部分，要灵活运用。比如一个很复杂的系统按照公司制定的流程可能从管理、资源、质量等都能够得到控制。但是如果系统本身很小，比如我刚刚接触的一个项目，功能很简单，如果完全按照公司的整套流程走的话，我估计效果不会很好，而且可能劳民伤财，还得不到预期的效果。所以对制度的执行要灵活，某些时候关键的内容作出来了，其他的边边角角我觉得可以不用深究，而且公司有时确实也是这么做的。有些项目就不完全按照CMM做，因为太浪费资源了。 |
||
|
[M] 能对前面提到的 SQA，SCM做一下解释吗？ |
||
|
[L] SQA是CMM中的软件质量保证的意思，SCM是CMM中的软件配置管理的意思。软件配置管理，是指在CMM中，软件开发过程存在3个库：基线库、生产库、产品库。基线库是在软件开发的初期建立起来的，比如需求、项目进度、计划等等，以后的软件开发以它为基础。并不是说不允许更改，但是更改的话需要走变更流程，需要先申请，后审核，审核通过了才允许补充进入基线库。生产库就是项目开发过程中存在的库，产品库就是项目开发完毕后的了，库中存放的大概就是一些文档、代码等等。当然你可以使用clear case来作为媒介，也可以使用source safe，这要视公司的具体情况而定。 |
||
|
[文档] |
||
|
[M] 你对程序员进行文档的组织、编写、维护工作持什么样的态度呢？这是否会影响coding呢？尤其是在来自客户和市场的压力十分严峻的时候。这是一个很现实的问题。 |
||
|
[L] 其实我们大家都不止一次的提到，在做项目的过程中大部分时间都是用来组织编写文档，真正coding的时间在整个项目的生命周期中占的时间是很少的，一个真正的项目也绝对不是以coding作为结束标志的，因为项目结束后还有维护或者二期甚至三期，所以文档的积累对于项目来说就是至关重要的事情。作为项目结果之一的代码，我们不能只让写这段代码的人知道，这无异于赌博，而且经过一段时间之后谁也不可能保证自己对自己曾经写过的代码一清二楚。我们要让所有的人知道某段代码应该实现什么功能，包含什么逻辑，是一个什么样的思路，这样项目转接工作才能做得更好。客户和市场的压力十分严峻的原因是什么，不可能因为程序员写文档造成的。相反如果文档写的好反而在coding阶段会节省很多的时间，因为思路、算法在文档中已经得到很具体的体现。如果真的客户和市场的压力十分严峻至少在项目结束后应该把文档补齐。如果只是项目经理写文档，那么他的思路、设计，在程序员身上很难得到体现。因此我建议程序员要参与到概设、详设的文档编写中来。其实，摩托罗拉就是很好的例子，他们不会因为某个程序员或项目经理走了，来接替他的人需要花费大量的时间来熟悉这个系统，相反他们可以从文档着手，很好的理解整个项目。我们公司就有很失败的例子，在给HP做的电子商务系统中，到现在某个页面可能被5－6个人更改过，但是最基本的概要设计连第一版本的内容都没有，因此现在维护相当的费劲，几乎没有人愿意接触这个项目，一点小小的改动，都要研究半天的代码。血的教训啊。 |
||
|
[M] 对于项目文档的准确，完整，应该如何去把握呢？ |
||
|
[L] 项目文档的准确，完整的定义可能很模糊，而且判断起来也很困难，但是我想最基本的应该是：项目初期应该把项目涉及到的内容全部写入文档，项目进行中可能某个思路不能得到实现需要更改，代码更改了但是文档一定要跟着更改，否则就失去了文档本来的意义。所以我想项目经理在做计划时是否每周要留出半天甚至一天的时间来修改文档？ |
||
|
[M] 项目文档化过程中，文档撰写者需要将思路精确无误的表达出来，并且阶段性地保持文档和代码的一致性。这对文档撰写者提出了一定要求。在你的公司里，当客户和市场的压力十分严峻时，又是如何保证这些的。对此你有什么看法或心得，你认为程序员需要具备什么额外素质吗？ |
||
|
[L] 其实写文档就是一个整理思路的途径，所谓的完整或许不需要面面俱到，但是重点的流程，关键的思路等都需要描述出来啊。其实对于文档的撰写，不要觉得是个很复杂的事情，文档的意义就在于它记录了项目的完成过程，在于便于以后项目的维护。当客户和市场的压力十分严峻时，我们的精力可能集中于项目的真正coding，专注于项目的按期完工。但是在项目结束之后项目文档一定要补全。现在国内的情况是程序员大部分是本科出身，因此程序员本身的素质就决定了他不止可以承担coding的任务，因此项目经理要适当的给予他们一些其他的额外工作。 |
||
|
[M] 文档具体包含哪些类型？每种文档针对何种阅读者？ |
||
|
[L] 文档包括：需求分析说明书，概要设计说明书，详细设计说明书（许多数据流图都作为文档的附件的），等等吧，现在我手上也没有很全的文档列表。 |
||
|
[M] 在你的公司，有没有类似程序设计说明这样的文档，若有，对于这类文档，撰写者若表述不清则会使阅读者难于理解。实际中是否存在这样的问题？ |
||
|
[L] 其实我觉得象概要设计说明书，详细设计说明书不知是否属于程序设计的文档，不过我觉得应该是吧。其实象这种文档如果撰写者表述不清对于阅读者的理解程度会有很大的差别的。我们公司也一直在讨论如何制定一个切实可行的规范，以利于大家把文档写的详细、清楚，我们现在的模板有时对于某些项目来说真的不适合。但是很长时间以来仍然找不到一个可以避免的方式。在现实的工作中，我认为是存在表达不清的，只不过我暂时没有遇到过，或许我从需求阶段一直跟到验收，所以对系统很了解，所以可能没有遇到不好理解的地方吧。而且现在公司的形式是每个人负责写一块的概要设计和详细设计，因此这份文档对于这个人来说很明白，但是没有人对整体文档的把握，虽然我们要做概要设计和详细设计的评审，但是由于大多数情况下时间不允许，因此项目成员写完以后，项目经理组织到一起也就完事了。 |
||
|
[M] 文档的意义或作用除了记录项目完成过程外，还有其他吗？ |
||
|
[L] 或许文档的意义重要的在于项目的"repeatable"，"repeatable"前几天刚刚从项目管理部经理哪里听来的新词，具体的含义我想大家可以讨论。或许文档可以帮助我们总结经验教训，记录我们突然间的思想的火花，遇到同样的项目可以提供经验。 |
||
|
[M] 在你的经历中，有否切实体会到撰写文档会便于以后项目的维护？ |
||
|
[L] 体会太深刻了，我们给HP做的惠普商桥系统，从开始到现在经手人估计将近10个了，但是文档仍然是第一版的，因此需要增加新的功能，如果是一个从来没有接触这个项目的人来做，假设代码的改动量是200行，但是他首先需要大概一天的时间来读以前的代码。这就是没有文档的结果啊。象摩托罗拉，他们的项目组中的任何一个人走掉以后都不会对项目组产生影响，因为他们的文档做的非常好。 |
||
|
[版本控制] |
||
|
[M] 在你的开发过程中，有否使用过版本控制措施？ |
||
|
[L] 我们公司的项目，无论大小都使用版本控制。特别是执行CMM标准后，项目一启动，在版本控制数据库中就建立很多的目录、资源文件等等。其实使用版本控制，就是避免两个人同时操作一份文件，当遇到改正的不对的地方时可以回滚，返回到上一个正确的版本。而且万一程序被几个人更改后可以记录更改人的姓名、时间，以利于寻找责任。其实团队开发时，版本控制是必须的措施。而且即使一个人开发，也建议使用版本控制，比如你更改了某些东西，但是发现更改的不对，想用Ctrl+Z但又不能恢复，这时就可以使用版本控制的“撤销签出”来获得上一个版本的代码。 |
||
|
[M] 你在实施版本控制的时候，有没有发生过因为人员版本控制意识不强，以及对版本控制工具使用不当，而造成的损失或效率降低呢？ |
||
|
[L] 应该说在实施版本控制时问题还是很多的，而且有些人对版本控制的认识还不是很清楚，认为版本控制没有太大的必要。在dot net开发环境下，我们曾经出现过一些问题，同事刚刚更改的文件，check in 然后check out发现仍然是原来的样子，也就是说他新更改的代码丢失了。但是换到另一个的机器上就发现代码是更改以后的，这样大概折腾了一上午的时间，后来也不知道什么原因就好了，不过倒是后来没有发现类似情况。 |
||
|
[M] 你个人对版本控制的实施有何心得？ |
||
|
[L] 其实对于版本控制的心得也谈不上，只是有一点source safe的小小技巧或者说小小经验而已。个人理解还处在比较低的水平，个人技巧也只是限于普通的应用。在小组协同开发过程中，我认为版本控制是必要的，毕竟小组开发人多，对于某个文件的操作可能同时几个人都会涉及到，如果没有版本的控制措施，两个以上的人可能同时操作同一个文件，这样就会相互冲突，造成代码的混乱。如果有了版本控制的措施，就可以保证一个文件在一个时间只能被一个人使用。当遇到修改错误的时候就可以恢复到上一次修改的版本，避免发生不知道修改何处，无法恢复的问题。还有一个问题是如果某个文件出现错误，可以找到最后一次修改的人员，到时他想否认都不可能啊。 |
||
|
[M] 如果在版本控制的过程中，由于操作不当，或人为疏忽，造成损失，对此有什么补救措施吗？ |
||
|
[L] 应该说在版本控制过程中，不同的人员对于项目文件的操作权力是不同的。项目经理可以add/delete/modify/destory，而项目成员则只能add/delete/modify。因为我没有遇到过操作不当的问题，因此我只能凭借个人的一点理解，给你大概的介绍一下。版本控制的工具对你所作的每一次操作都会记录下来，保存为历史记录，由于项目成员只有delete的权力，因此如果把某个文件不小心删除后，应该可以通过历史记录查找出来，但是如果项目经理把文件destory后，在版本控制的历史记录中可能就找不到了。不过如果项目成员想要修改某个文件，他必须在本地建立一个项目副本，然后本地修改，因此即使在版本控制中把文件删除，通过其他项目成员的本地副本仍然可以得到某个版本的代码，但是这个版本是否是最新的值得怀疑，因为最近该项目成员可能没有get last version。所以如果操作不当，或认为疏忽造成损失之后，应该可以弥补一部分，但是是否是全部弥补，要试具体情况而定。因此项目经理的另一个任务就是每天备份代码，数据库等重要的项目信息。这样可以把意外情况的损失降低到最小。 |
||
|
[其他] |
||
|
[M] 对于代码的规范以及注释的书写，你有何心得呢？ |
||
|
[L] 在我刚刚完成的项目中，有个程序员以前是写Notes的，对于sql server不是很熟，因此在写代码时定义了一堆的tmpstr1，tmpstr2等类似的变量，变量具体对应窗体上哪个控件的内容，你必须找到变量赋值的地方才能看到变量对应的具体内容。而且从来不加注释，整个页面包含不同的函数，确使用一个connection链接，出现了错误，调试都找不出原因，非常的困难。所以我就要求他们必须加注释，可以说是强迫他们吧。由于工期比较紧倒是没有要求他改正页面的代码。我们公司在制定CMM标准时，整理了一套编程规范，项目开始时给程序员人手一份。我原来设想在项目过程中隔一段时间抽出2－3个小时把某个程序员的代码讲一下，人为的让大家养成比较好的编程习惯，可惜项目太紧，我没有执行。其实代码的规范和注释可以说是文档的一部分，规范好注释好，对于维护人员来说相对的就轻松很多。 |
||
|
[M] 你在回答有关代码规范注释书写的问题和版本控制的问题时都提到了CMM，CMM和这些有什么必然联系吗？这些是在CMM中有所提及，还是对CMM实施的一种延伸。 |
||
|
[L] 我觉得CMM可能和这些东西没有必然的联系，因为CMM的培训我们公司最近一直没有做，我只是根据同事的聊天以及自己的一些个人想当然的理解说的，但是我觉得这些应该是CMM的一种延伸。在CMM的定义中有一种名为"SQA"的角色，就是质量保证员，他的工作可能就是保证提交给客户的代码的质量，或许有些版本控制的味道吧。其实代码注释的规范编写，我觉得我们可以理解为代码质量的一种表现形式。我觉得代码质量的衡量不应该仅仅是软件在客户处运行正确，没有bug，还应该包括代码是否利于维护。一个项目维护人员他首先看的可能就是项目文档和代码，但是由于项目文档可能不是很全，很正确，因此维护人员的最直接的工作可能就是看代码，如果代码写的很晦涩，而且又没有必要的注释，那么对应维护人员来说是很头疼的事情。这样可那与CMM的初衷有些背离。 |
||
|
全文完。 |