UML软件工程组织

Morning对Leo的采访

作者: Leo，晨光（Morning）

我的一位同学（Leo）目前正在一家软件公司工作。一段时间之前，在我的提议下，我以私人的身份对他进行了采访。我们以mail的方式进行了多次交流。以下是经过整理后的谈话内容，主要内容涵盖：项目管理、CMM、文档、版本控制等。希望这篇来自“一线”的文章会给大家带来启发，也欢迎大家共同讨论，并提宝贵意见。以下文章中，M代表我，L代表我同学。

声明：本文版权由Leo与Morning共同所有。
[开场]
[M] 你能对你目前的软件开发所涉及的应用领域做一个扼要的介绍吗？

[L] 首先我们公司的目标是软件外包，因为时机还不是很成熟，或者暂时还没有那么强大的市场竞争力，所以我们也要做国内的项目，作为过渡。而且我们公司是一个资源公司，所谓资源公司也就是可以短期或长期的给客户提供一定的人力资源。比如IBM的某个项目突然需要很多人，但是他们不想自己招人，因此他们就来找我们公司要人。至于我所涉及的领域主要是渠道销售网的建立以及维护，属于电子商务。大部分都是针对企业内部具体情况而定的一些项目。

[M] 你的team work规模如何？

[L] 我进入公司以后所经历的最大的项目组就是5个人。在我们公司一般的项目都是5－8人的，小项目基本就是1，2个人。

[M] 在team work中，你的职责是什么，起着什么样的作用？

[L] 既是coding人员，同时也担任着项目经理的角色。
[项目管理]
[M] 在一个team中，程序员的主要职责是什么呢？

[L] 作为程序员来讲，主要的职责就是要保质保量按时的完成项目经理分配的任务。在CMM中强调大家的整体参与，项目过程文档化。所以作为程序员来说在实施CMM的过程中，不应该只是coding的角色，还应该参与文档的编写。因为在CMM中项目过程文档化对项目经理来说是一份很大的工作量，因此必须把一部分文档交给程序员来写，因此此时程序员的工作多了文档的组织、编写、维护的工作。还有程序员还应该及时参与项目经理的整体设计，以及框架结构的设计等设计工作，要意识到如果项目经理的一步错可能的责任在他，但是工作量的直接增加是在于程序员。作为程序员还应该注意代码的规范以及注释的书写。

[M] 那么，在team中，项目经理的主要职责又是什么呢？

[L] 作为项目经理，主要的职责就是在一定的时间内使用给定的资源按时完成项目，并且达到客户、公司双满意。在项目组要起着模范带头作用，要用积极的态度来对待这个项目，要以身作则，如果加班的话，项目经理必须来，即使你来了没有什么太大的用处，要会拉拢人心。要监督项目的进展情况，这是至关重要的一点，比如在我们前一段时间做完的项目管理系统来说，我虽然名义上是项目经理但是我被代码压的喘不过气来，因此就没有时间来review程序员的代码和工作，而我的Owner也没有做这部分工作。虽然项目按时完成了，但是我感觉有极大的隐患。项目经理还要做到知人而用。要注意项目文档的准确，完整。

项目经理在项目组和公司之间起着协调资源的作用，因为项目经理要和项目管理部接触，及时的相互通融项目的进展情况，要按照公司的标准做事。如果发现项目进行过程出现时间不够、人手不够等情况，要及时的向你的领导反映要求增加人手或脱后时间等。项目经理在开发部和测试部之间也起着协调的作用，要帮助测试部搭建测试环境，要分配测试部提交的defect，要监督defect的完成情况。

最后最关键的，就是项目经理在公司和客户之间的职责了，项目经理在公司和客户之间起着桥梁的作用，要把公司最近的情况向客户阐述，还要把客户的要求及时准确的反映给公司的领导。因此遇到客户的需求变更、项目验收等问题时一定要注意自己的说话语气，做事的方法态度等，否则后果就是走人，如同我的leader。遇到客户的问题觉得扛不住时一定要及时的汇报给领导，因为万一公司和客户的关系僵了，这个责任自己是承担不起的。对待客户要不卑不亢。

[M] 你所说的Owner是一个什么角色？

[L] Owner的概念，在IT业内可能是我们公司的一个特色，因为我们公司的项目经理都很年轻，没有什么经验，因此项目来时公司会分配一个项目经理，然后分配一个Owner，在项目经理之上管理这个项目。不过Owner一般没有什么作用，绝大部分的工作都是项目经理完成，只不过当项目过程出现重大变更时Owner可能起绝对性的作用。这种Owner应该相当于公司的部门经理的作用吧。

[M] 在与客户的交流中，你或者你的同事有过不愉快的经历吗？如何处理这种情况呢？

[L] 我觉得与客户的接触中需要做到不卑不亢，对于客户提出的需求，属于范围内的，就没有任何怨言的修改，如果超出范围则需要讨价还价。不过，其中有个方式的问题。这点我承认做的不是很好，但是需要慢慢锻炼。比如：我们刚刚完成的项目中，我们安装交付之后，客户提出需要修改某些东西。我的leader直接就说这属于需求变更需要加钱，而且我的leader很自傲，说话不注意分寸，因此遭到客户投诉，搞的客户关系很僵，最后的下场就是遭到公司的开除。所以现在遇到需求变更我就先不答应也不驳斥，我说回公司找领导研究一下。当然我是真的找领导，如果领导说让我告诉客户需要付钱，则我就说属于需求变更，可能收费，如果领导说做吧，好我做。反正有什么问题有领导顶着。如果客户关系已经很僵了，则需要灵活的处理了。比如经常打电话问候一下软件运行情况，出现bug更新的速度快一点等，让客户感觉到公司很重视他们。和客户说话一定要注意，要表现出来我已经尽了200％的力量。如果动员全公司的技术高手来解决一个问题，仍然没有结果，就可能需要考虑更换另一种方式来实现。

[M] 在你的公司，似乎对项目经理在技术方面有较多的要求。而有的公司似乎项目经理更偏重于管理和资源筹划，有些对技术可能并不很了解。对此你是怎么看的呢？

[L] 应该说我们公司的情况是比较特殊的，或者说中国的模式就是这样的，项目经理一般都是从做技术开始，慢慢接触管理的。我们公司的项目一般比较小，而且有时人员编制又不足，这样就导致项目经理既负责管理和资源策划，又要参与一部分的coding、技术工作。而且项目成员遇到技术问题，项目经理就必须竭尽全力去帮助他解决，因此要求项目经理必须掌握一定的技术。不过我们公司也在慢慢的改变这种境况。首先项目经理分配工作时就要考虑到项目中可能遇到的各种问题，然后自己coding的工作会比较少，大部分精力放在管理和资源策划。而且项目经理的资源策划以及管理的权力也在逐步变大，经验也在慢慢增加。不过我倒是从来没有真正的自己带领一个团队工作过，而且自己在管理以及资源策划方面的能力也不是很足。公司Owner的作用也在慢慢的消弱，具体的与客户的交互，与公司其他部门的协调，与测试部的协作，现在的项目经理都是一人独掌。

[M] 项目经理是否必须懂技术？你是怎么看这个问题的。我曾经遇到过的一种情形，是在一个teamwork里安排一个项目经理和一个技术负责人。你觉得这样的方式是否可行呢？

[L] 个人认为项目经理还是适当懂一些技术比较好，但是如果真是如你所说安排一个项目经理和一个技术负责人的话，或许项目经理是否懂技术也就变得无所谓了。

还有一种情况就是，象我们公司现在进行工作量评估，这样的话项目经理可以不懂技术。

我认为项目经理适当懂点技术的出发点是：项目经理在做计划时需要考虑某个模块的工作量。如果模块工作量已经估计出来了，那么项目经理可以直接根据这个工作量来安排计划。好多时候是项目经理在估计模块的工作量，因此如果项目经理对于这项技术一点不懂，不知道某个模块可能遇到的技术难点以及解决这个难点需要的时间，那么在做计划时可能就会不准确。

但是我们公司现在的情况允许项目经理不懂技术，原因是工作量的评估是许多人的加权平均值。我们的流程，一般是在项目需求确认后开始工作量的估算，这个时候要求项目经理按照需求功能拆分很多不同的功能点。理论上，拆分地越细，工作量的估计就越准确。每个人对于每个功能点都存在一个乐观值、一个悲观值、一个可能值，三个数的加权平均就是某人对于某功能点的工作量。很多人对于某功能点的加权平均就是该功能点的工作量。最后给客户的报价也是按照该工作量来报的。项目经理可以按照公司评估出的工作量来制定项目计划。当然，遇到技术问题可以找项目管理部来让他们帮助找人解决。

[M] 在小型开发团队中，你是否认为，成员职则彼此都较模糊，或者说互有交叉。人员相互弥补不足，对leader来说压力可能也会小些。在这样的环境下，个人自由与纪律规范是一对矛盾，如何处理这个矛盾，如何把握这个度呢？

[L] 其实现在我所接触到的开发团队中，成员的职责应该说是比较清楚的。某个模块由谁来做，什么时间交付定义的都十分清楚，而且功能相近的模块也不可能交给多个人做，除非工作量很大。至于具体的职责问题我想项目成员应该是保证自己的代码、文档的质量，当然他也要对项目有一定的责任心。在开发团队中人员相互弥补对于整个项目来说肯定会有很大的益处，这样项目经理就不用帮助协调技术等问题了，就会有更多的时间来管理项目。在开发团队中个人自由与纪律规范是非常尖锐的矛盾，对于度的把握就更难以衡量了，我觉得只要不影响项目的进度，不影响项目的质量，遵守公司的各种规范，有些问题是可以通融的。其实团队开发关键是一个professional的问题。属于工作范围之内的，要没有任何理由的按时完成；不属于工作范围之内的问题尽量少搀和。不过工作范围的界定可能又是一个问题吧。其实也可以这么理解，如果你的编程能力很强，只用了2天的时间就完成了项目经理交给的5天的工作量的话，那么剩下的3天你会干什么？继续写以下的代码？还是学习？我想应该是学习吧。你不能接着写以下的代码，因为你不知道项目经理所安排的本属于5天工作时间之后的后续工作，可能他要一个中间阶段的测试等等。但是由于你急于赶工，因此导致了他的中间阶段的测试不能执行。还有，项目成员要统一开发语言，我们公司有个EPSON的项目，除了一个人之外其他的成员都使用delphi5，只有这个程序员用delphi6，你说项目经理能不生气吗？

[M] 你在前面提到的项目管理部是一个什么样的机构？

[L] 项目管理部就是公司的一个专门讨债的部门，整天追着项目经理要文档:)。其实怎么说呢，他们就是负责监控项目的整个流程，特别是现在要做CMM，更是需要项目管理部。因为SQA，SCM等都是贯穿整个项目始终的，而且还起着比较重要的作用（有关SQA，SCM的问题请见后）。因此项目管理部的工作显得比以前更为重要。而且我们以前项目的源码、文档等都在项目管理部有备份，自己如果不小心丢了，还可以找项目管理部要，如果他们也丢了，责任就大了。总之项目管理部就是监督项目的流程，控制项目的质量，而且像需求变更等都需要项目管理部的参与。

[M] 是否可以认为，项目管理部是在项目队伍不够成熟的前提下才产生的，它既起主导作用，也有辅佐作用，并且该部，对公司的所有项目组统一负责？

[L] 项目管理部的主要的工作就是跟踪，管理所有项目的整个流程。特别在CMM中，我觉得它存在的必要性就更大了。其实它不应该说成在项目队伍不够成熟的前提下产生的，或许应该说成随着项目队伍的成熟，随着公司的规范，它可能要发挥越来越重要的作用了。

[M] 为什么你认为项目管理部随着项目队伍的成熟，随着公司的规范，可能会发挥越来越重要的作用呢？

[L] 我感觉随着公司的规范操作，项目过程中的各种问题、流程、以及解决方案，都会得到很好的积累。积累的结果不可能局限于某个项目组，某个项目成员。也就是说不可能是某个人具有这种积累，而应该是公司具有这种积累。公司就需要把这种经验总结下来，保存下来，项目管理部正好可以起到这种作用。既总结项目经验，又监督项目的执行，还提供一些经验促使项目少走弯路。在CMM中，项目的各种操作有严格的定义，项目经理可能不是很成熟，或者没有足够的时间来应付各种各样的工作。此时如果派其他的项目经理来监督可能效果不是很好，因此项目管理部就可以派人员进入到项目组，在项目的特定阶段监督项目的执行。

[M] 对review程序员的代码和工作，你一般是如何做的？

[L] 迄今为止，我还没有真正的单独带领一个团队工作过。在我们刚刚结束的项目中，我名义上是项目经理，但是因为还有一个owner，因此我大部分的精力就是coding，然后就是帮助项目组成员解决技术问题，当然某些项目经理的工作我还是稍微接触了一下。因此对于项目模块功能的review，对于代码的review，我都没有做，因为我自己的coding任务太艰巨了。不过如果真的是我，我想首先项目经理应该按照项目计划每天检查项目成员对于功能模块的完成情况，这是项目经理最基本的工作。你必须检查项目成员的进度，适当的调整项目计划。然后在项目时间不是很紧的情况下要review程序员的coding，因为虽然程序员把功能实现了，但是代码可能隐藏着很大的隐患。适当的培养程序员的编码规范意识，这样对于程序员个人，还是公司都是一个很好的积累。

在我们公司曾经有一个项目经理每天要两次调整项目计划，他带项目真的是很认真，很有一套经验的。我们公司还有一个team，当项目经理review某个程序员的代码时发现一个页面中竟然使用了10个以上的recordset(记录集)，这种代码的质量太让人难以接受，虽然功能实现了，但是隐患呢？很危险。因此项目经理很生气的把该程序员训斥了一通。

[M] 你是否认为，对需求的正确理解将直接影响项目开发的后续工作。实际情况，往往是用户自身对需求的认识也并非总是清楚的和一尘不变的，对此，你怎么看呢？

[L] 对需求的理解肯定会影响项目开发的后续工作。因此在市场前期对销售人员，以及对参与需求调研的人员的能力，就有比较高的要求。他们要准确把握用户的需求而且要挖掘用户的隐含需求，特别是对于用户自身对需求也认识不清的情况，更需要前期的人员有很高的能力。用户需求不确定是一个不可避免的问题。在任何项目中，这种问题都会出现，所以我们公司对于需求变更，一定比例之内是无条件更改的，对于超过比例的就需要收费了。在需求调研阶段，我们往往是做demo，要求用户确认。通过demo，用户的要求和我们的理解就能比较好的达成一致。

[M] 需求变更超过比例的需要收费，则公司无形中承诺了这种变更将不会使项目出现问题，这一点团队成员上下都需要保证的，那么，如何保证呢？有没有反例呢？

[L] 其实任何公司都不会允许客户无休止的更改需求，因此需要采取某种手段来制约客户的需求更改，我想收费的目的也就在于此吧。至于目的是否能够达到，效果如何，最终是否把需求变更的钱收回来是具体另一回事了。

[M] 我想知道在你所在的公司，在项目开发过程中，是否存在由于需求变更的程度很大，而导致项目形势很糟糕这样的现象，或者由于采取适当措施而“化险为夷”的事例？

[L] 由于需求的变更导致项目的问题我倒是不太敢确定，不过我曾经接触的项目中由于客户的不成熟，或者说双方对需求的理解不够导致项目验收拖延的事情确实存在。

[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的初衷有些背离。