神马文学网项目管理的经历
来源：百度文库 编辑：神马文学网 时间：2024/04/27 14:23:09
项目管理的经历:
今天的阳光很猛，让我心潮澎湃。在早上的会议，老板任命我为项目主管，负责公司WEB系统新增功能开发工作。这是我第一次全面负责软件项目开发。在这过程有成功的喜悦，也有很多失败的教训。我将自己的感受和体会写出来，与大家共勉。
一． 第一天收到的三份礼物
项目成功核心在于管理
对我而言，这个任命是意料之中，在过去的几个项目我作为程序员都表现非常漂亮。我怀着无比激动的心情迷糊之中回到自己的办公室，兴奋令我久久难以平静。这个时候，老板走进我的办公室，笑眯眯的看着我说：“嗯，今天是你第一次全面负责项目吧，作为程序员你的表现我就不多说了。今天我送你一句话当作勉励，程序开发是软件项目的核心，但缺少管理和受控的开发过程，肯定不会在有限时间和成本内作出高质量的软件产品。从今天开始你需要转变角度，从一个项目主管角度思考和处理问题”。
老板走后，我独自在办公室思考着老板的这句话。在我过去作为程序员的开发过程中，程序员都是根据主管制定好的开发计划，已有的模块设计文档，然后编写程序。而从今天开始，我不只是一个程序员，更重要的是要从管理和受控的角度来思考如何在规定时间，有限成本完成项目，这是摆我前面的第一个考验。
项目第一步是制定开发规范
窗外，太阳灼烧大地，也灼烧着我的心。在我还在迷糊思考如何开展项目管理的时候，公司CIO张力走进了我的办公室，他也是我良师益友。
他拍了拍我的肩膀，哈哈的笑着说，“怎么样？第一次做项目负责人感觉如何？我看你好象很紧张啵？”我看着张力，也不好意思的笑了，象看到救星一样说：‘张总，我正想向你请教呀，项目第一步的关键是什么？”
张力说：“你作为程序员已经参加了各种的培训，如软件工程思想，项目管理以及CMM和ISO9000等等。我提醒一个就是首先需要先制定好你的开发规范和开发流程”。
“还记得我给你们培训时说掌握软件工程思想，对软件开发负责人更为重要吧。没有软件工程管理，所有的事情都会乱七八糟。我们已经知道软件和程序是两个不同的概念，软件除了程序还要有使用和维护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、维护文档以及使用手册”。
从另一个方面看，要保证系统的协调性、统一性和连续性,也需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费一定的时间和精力,但是"磨刀不误砍柴功"。开发规范主要包括:需求文档、系统设计规范、程序开发规范和项目管理规范等。它约束开发人员的行为和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契，以便形成整个系统的和谐步调和统一风格，也便于今后的系统维护和扩展工作。
沟通与掌控
窗外，阳光很眩目，当我正要甩开膀子准备制定开发规范的时候，办公室又走进一个人，是公司的人力资源副总陈迹。他看着我意气风发的样子，笑着说：“怎么样？火星，看你现在的样子，你要去打架斗殴吗？”。哈哈，风趣是陈总的风格。我连忙说：“陈总，我正想向你请教如何管理人的问题”。陈迹爽朗的说：“我刚刚看到老板和老张来过你的办公室，我也来送你一份礼物吧，就是你需要时时记住，项目不是一个人在单打独斗，需要时时与你的组员进行沟通和掌控”。
后来，我们还谈了许多，陈迹认为项目负责人是对整个项目有控制和决定权,对项目开发的成败负责。软件开发中遇到问题的答案往往不止一个，因此需要有人对这些问题有决定权，避免扯皮。项目主管还要与组员沟通Weekly Report。包括目前进度，质量状况，各种工作的进展等。一般来说程序员都讨厌开会，但项目组至少每周全体开会一次，主要包括团队交流，规格讨论，bug诊断与处理，大家千万别闷头写代码。同时所有会议、讨论都要有记录。会前发会议议程，会中有人负责主持和记录，会后有人负责发会议摘要，这都是高效会议的要点。
陈迹还说到一个非常有用的管理技巧，就是为项目组建立多个Mailing Group，这样发起邮件来方便，而且能让该收到电子邮件的人都收到、不该收到不被骚扰。通过电子邮件进行正式沟通的好处是免得抵赖，以后也可以时时阅读。但也要避免矫枉过正，为了加强沟通最好的方法是先用电话和当面说，然后Email来确认。
二．需求分析的教训
编码，是软件过程中一个实现的环节。说起编码，感觉谁都能做，但做得好的确不多。我以前觉得写代码是最麻烦的事情，经过项目初期挫折的磨练我才发现写代码只是软件开发中最简单的一个步骤。最关键的第一个步骤是需求分析，就是要确定自己要做什么，应该怎么做，心里有个底。如果没有对需求进行分析，可能出现项目设计出来的东西或最终提交的根本就不是所需要的，或有相当的差距。
需求规划是根据具体需求情况分析和规划出一个最终需求文档。需求规划就像高楼的地基，如果马马虎虎，就算是一块砖块没摆好都可能导致整个高楼建设的失败。目前，很多开发人员深感项目的需求文档写得都很单薄，不够细致。对于一个缺乏需求管理的软件项目而言，必定会导致系统不能实现预期的功能而需要在后期进行昂贵的修正，使得项目拖期、产生严重的质量问题与超出项目预算的现象。
了解真正的需求，可以让我们在软件的开发过程中少走很多的弯路，缩短软件开发的周期，提高软件的友好性，易操作性，易用性，从而来提升软件的质量。
三． 项目控制两大关键
在我埋头苦干的时候，出现了两个让我措手不及的问题。就是有一天，CIO张力要求我把项目的管理文档和项目中出现的问题管理资料给他参考，他想了解项目开发的情况。
张力认为，如果一个项目的每个步骤实实在在的眼皮底下进行，而且随时可以翻阅，那么这个项目的成功一定不会远了。开发过程的管理也是这样，控制每一个细节，就会水到渠成。结果是由每个细节的过程来决定的，这需要控制好每个开发的细节，从管理文档和问题管理这两个方面就能直接看出项目控制得好与坏。
管理文档
开发中我遇到许多开发人员会把工作进度报告看成是一种很重的负担，他们认为他们是做开发的，不是写报告的，花时间写报告还不如多写几段代码。实际上这是非常大的误解，进度文档的理念就是清楚的记录每个事情的状态。所有事情都记录在案，可以一目了然完成了哪些模块，更正了哪些问题。文档的管理还有另一个好处就是容易翻阅历史资料，减少内耗和误差，这一点我在项目中体会很深。
开发流程不是操作复杂，就说明管理好；也不是稿纸写一写，会议开一开，就可以。最关键的是适合，看得见，管得着。从项目的需求分析、系统分析、编码、调试、测试、发布都需要一步一步完成，不能轻视或忽略任何一步骤。软件项目开发普遍存在忽视规范化，随心所欲，没有计划，想到哪做到哪，其最终的结果是失去控制。那种认为只要产品做出来可以运行，何必花费许多精力去做文档的观点是错误的。经过实践，我深刻体会到，没有文档会带来很多问题。我认为文档应该是开发中每段时间的里程碑标志，每个阶段后都要提交相应的文档，这样可以用文档去引导开发过程，从而抛弃随心所欲的开发模式。
确保文档质量的最有效方法就是评审，提交文档后，组织相关人员对该文档进行审核，在充分讨论的基础上进行文档的重新修改和审核直到满足项目要求。在不同的阶段，需要不停地对文档进行完善，使之真正成为贯穿整个过程的主线。
问题管理
在开发过程让我感受非常深刻的经验是，每个人都需要知道出了问题应该找谁。我们在开发过程中不可能是一帆风顺的，不时地会遇到各种各样的问题，而如何解决问题，或者说是如何想办法尽早的解决问题，这个才是关键。而其中的最关键是不能有了问题而一声不响，闷头苦干，结果几天下来以后，却发现自己还是站在原地，而就算是你通过了几天的努力完成了这个难题。但是这样就是不是意味着你的成功了呢？
这样不但自己的进度没有办法完成，更会延误了整体的开发进度，别的成员就可能因为你一声不响地没有成果的努力，而不能再继续下面的开发。应该说软件开发过程中遇到问题一声不响、埋头苦干的做法是很愚蠢的，软件开发要求的不是个人英雄主义精神而是团队的整体合作精神。缺乏团队的意识的个人和团队必定是一个失败的开始。
就开发人员而言，一旦碰到了难以解决的问题，不仅要自己努力调查，想办法解决，一方面也要把存在的问题向PM反映，让PM能够知道存在的问题，而PM可以在进度会议、或者召开临时紧急会议，把问题摆出来，通过大家来寻求解决的方案。一个人的力量毕竟是有限的，而个人的英雄主义是团队开发的极大阻碍。
四．痛苦的进度管理
正如夏日的太阳一样，一直在灼烧我的心的是对进度的控制。进度管理是软件开发中最难以做好的一项工作。编程工作本身是一个难以量化的工作,再加上开发过程中对设计的修改等因素,使得项目开发工作经常不能按预计的时间完成。
开发人员最担心“领导不断催促，可系统提交日期一拖再拖”，项目负责人对此一筹莫展，束手无策。开发活动如同一个黑箱子，资金扔进去了，人员扔进去了，设备资源扔进去了，但不知道什么时候会出来结果，更没有把握出来的东西是否是用户所要的东西。
为避免人力、物力、财力浪费，就要进行有效的时间进度控制。在进度管理上主要有两点，一点是总体进度，另一点就是个人进度了，而总体进度是建立在个人进度的基础上的。
很多的人可能会以为，进度管理就是leader或者说是项目经理的事情，而与团队的其它开发人员毫无关系。其实，我认为这样的认识是非常的错误的，开发人员和所有过程都应该是有关联的。总体进度应该由PM来控制和调整，而个人进度却是软件开发人员个人的责任和职责所在。很多时候开发人员可能会抱怨，开发时间本来就少，每天又让我们写这种毫无意义的个人进度报告，这样就会浪费更多的时间。
其实不然，没有良好的进度控制管理，拥有再精英的团队也是白搭。开发人员在很多时候都是站在自己的出发点进行思考，相互间的沟通也只是个别人员之间的交流，并不能从根本上把握全体进度，也无法对进度作必要的分析和调整。而开发成员的个人开发进度报告汇总以后，能够让PM清楚的知道什么地方存在着问题，从而从项目整体上调整进度，决定相应的对策。
我的做法是每周将项目进度情况与项目进度计划进行对比。对于拖延的工作如无充份理由,我则会督促有关人员加班或提高工作效率赶上进度。如有正常理由,在无法追回的情况下就可以修改进度计划。在这里，我建议在软件开发的过程中，不管项目的大小我们都应该抽时间来写一份个人的进度报告，而在个人进度报告上应该有清晰的个人进度，存在问题，准备如何解决等等记述。总之，一句话，报告要简明扼要能够清楚地反映个人的进度状况以及存在的问题。
同时个人进度管理也是开发人员的自我管理，是进度控制的最重要组成部分。个人进度是总体进度的基础，个人进度的状况好坏直接影响到团队总体的进度推进状况。
五．配置管理的重要性
在项目取得一定进展的时候，我们会为之兴奋。在这里我想说说对配置管理（Software Configuration Management）的看法和理解。配置管理简单说可以是版本控制管理，但配置管理并不仅仅是版本的控制管理，还应该涉及到代码协调、履历追踪、品质检查等等细节的问题。
为什么我们要在软件的开发过程中引入配置管理？其实不为什么，在前面我也曾经提到过，软件的开发是团队行为，是合作，而不是个人英雄主义的自我表现。配置管理就是对软件开发过程中的产品（这里是说产品，而不是代码，因为我们的软件开发还包括各类文档，会议记录等等）进行标识、追踪、控制的过程，目的就是为了减少一些不可预料的错误，提高生产率。
一般来说可以使用配置管理工具来提高效率。例如常用的有VSS和CVS。一个好的配置管理工具应该具备这样的功能：一是并行开发支持，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制。二是履历管理，也就是修改的历史记录的可追踪性。能够明确地知道什么时候，谁作了什么，为什么怎么做。从而达到管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。
结束语
最后，我建议对项目开发中容易出现的问题，项目组内部应该举行技术交流讲座。每一两周搞一次内部的Tech Talk或者Chalk Talk。让组员之间分享技术心得，这比花钱送到外面去培训划算。
在这次作为开发负责人中，我学习到在开发过程中必须处理好四个关键问题，这四个关键问题为：人员沟通、规范、测试、进度控制。只有严格把关，才可以大大提高软件的质量。
今天的阳光很猛，让我心潮澎湃。在早上的会议，老板任命我为项目主管，负责公司WEB系统新增功能开发工作。这是我第一次全面负责软件项目开发。在这过程有成功的喜悦，也有很多失败的教训。我将自己的感受和体会写出来，与大家共勉。
一． 第一天收到的三份礼物
项目成功核心在于管理
对我而言，这个任命是意料之中，在过去的几个项目我作为程序员都表现非常漂亮。我怀着无比激动的心情迷糊之中回到自己的办公室，兴奋令我久久难以平静。这个时候，老板走进我的办公室，笑眯眯的看着我说：“嗯，今天是你第一次全面负责项目吧，作为程序员你的表现我就不多说了。今天我送你一句话当作勉励，程序开发是软件项目的核心，但缺少管理和受控的开发过程，肯定不会在有限时间和成本内作出高质量的软件产品。从今天开始你需要转变角度，从一个项目主管角度思考和处理问题”。
老板走后，我独自在办公室思考着老板的这句话。在我过去作为程序员的开发过程中，程序员都是根据主管制定好的开发计划，已有的模块设计文档，然后编写程序。而从今天开始，我不只是一个程序员，更重要的是要从管理和受控的角度来思考如何在规定时间，有限成本完成项目，这是摆我前面的第一个考验。
项目第一步是制定开发规范
窗外，太阳灼烧大地，也灼烧着我的心。在我还在迷糊思考如何开展项目管理的时候，公司CIO张力走进了我的办公室，他也是我良师益友。
他拍了拍我的肩膀，哈哈的笑着说，“怎么样？第一次做项目负责人感觉如何？我看你好象很紧张啵？”我看着张力，也不好意思的笑了，象看到救星一样说：‘张总，我正想向你请教呀，项目第一步的关键是什么？”
张力说：“你作为程序员已经参加了各种的培训，如软件工程思想，项目管理以及CMM和ISO9000等等。我提醒一个就是首先需要先制定好你的开发规范和开发流程”。
“还记得我给你们培训时说掌握软件工程思想，对软件开发负责人更为重要吧。没有软件工程管理，所有的事情都会乱七八糟。我们已经知道软件和程序是两个不同的概念，软件除了程序还要有使用和维护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、维护文档以及使用手册”。
从另一个方面看，要保证系统的协调性、统一性和连续性,也需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费一定的时间和精力,但是"磨刀不误砍柴功"。开发规范主要包括:需求文档、系统设计规范、程序开发规范和项目管理规范等。它约束开发人员的行为和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契，以便形成整个系统的和谐步调和统一风格，也便于今后的系统维护和扩展工作。
沟通与掌控
窗外，阳光很眩目，当我正要甩开膀子准备制定开发规范的时候，办公室又走进一个人，是公司的人力资源副总陈迹。他看着我意气风发的样子，笑着说：“怎么样？火星，看你现在的样子，你要去打架斗殴吗？”。哈哈，风趣是陈总的风格。我连忙说：“陈总，我正想向你请教如何管理人的问题”。陈迹爽朗的说：“我刚刚看到老板和老张来过你的办公室，我也来送你一份礼物吧，就是你需要时时记住，项目不是一个人在单打独斗，需要时时与你的组员进行沟通和掌控”。
后来，我们还谈了许多，陈迹认为项目负责人是对整个项目有控制和决定权,对项目开发的成败负责。软件开发中遇到问题的答案往往不止一个，因此需要有人对这些问题有决定权，避免扯皮。项目主管还要与组员沟通Weekly Report。包括目前进度，质量状况，各种工作的进展等。一般来说程序员都讨厌开会，但项目组至少每周全体开会一次，主要包括团队交流，规格讨论，bug诊断与处理，大家千万别闷头写代码。同时所有会议、讨论都要有记录。会前发会议议程，会中有人负责主持和记录，会后有人负责发会议摘要，这都是高效会议的要点。
陈迹还说到一个非常有用的管理技巧，就是为项目组建立多个Mailing Group，这样发起邮件来方便，而且能让该收到电子邮件的人都收到、不该收到不被骚扰。通过电子邮件进行正式沟通的好处是免得抵赖，以后也可以时时阅读。但也要避免矫枉过正，为了加强沟通最好的方法是先用电话和当面说，然后Email来确认。
二．需求分析的教训
编码，是软件过程中一个实现的环节。说起编码，感觉谁都能做，但做得好的确不多。我以前觉得写代码是最麻烦的事情，经过项目初期挫折的磨练我才发现写代码只是软件开发中最简单的一个步骤。最关键的第一个步骤是需求分析，就是要确定自己要做什么，应该怎么做，心里有个底。如果没有对需求进行分析，可能出现项目设计出来的东西或最终提交的根本就不是所需要的，或有相当的差距。
需求规划是根据具体需求情况分析和规划出一个最终需求文档。需求规划就像高楼的地基，如果马马虎虎，就算是一块砖块没摆好都可能导致整个高楼建设的失败。目前，很多开发人员深感项目的需求文档写得都很单薄，不够细致。对于一个缺乏需求管理的软件项目而言，必定会导致系统不能实现预期的功能而需要在后期进行昂贵的修正，使得项目拖期、产生严重的质量问题与超出项目预算的现象。
了解真正的需求，可以让我们在软件的开发过程中少走很多的弯路，缩短软件开发的周期，提高软件的友好性，易操作性，易用性，从而来提升软件的质量。
三． 项目控制两大关键
在我埋头苦干的时候，出现了两个让我措手不及的问题。就是有一天，CIO张力要求我把项目的管理文档和项目中出现的问题管理资料给他参考，他想了解项目开发的情况。
张力认为，如果一个项目的每个步骤实实在在的眼皮底下进行，而且随时可以翻阅，那么这个项目的成功一定不会远了。开发过程的管理也是这样，控制每一个细节，就会水到渠成。结果是由每个细节的过程来决定的，这需要控制好每个开发的细节，从管理文档和问题管理这两个方面就能直接看出项目控制得好与坏。
管理文档
开发中我遇到许多开发人员会把工作进度报告看成是一种很重的负担，他们认为他们是做开发的，不是写报告的，花时间写报告还不如多写几段代码。实际上这是非常大的误解，进度文档的理念就是清楚的记录每个事情的状态。所有事情都记录在案，可以一目了然完成了哪些模块，更正了哪些问题。文档的管理还有另一个好处就是容易翻阅历史资料，减少内耗和误差，这一点我在项目中体会很深。
开发流程不是操作复杂，就说明管理好；也不是稿纸写一写，会议开一开，就可以。最关键的是适合，看得见，管得着。从项目的需求分析、系统分析、编码、调试、测试、发布都需要一步一步完成，不能轻视或忽略任何一步骤。软件项目开发普遍存在忽视规范化，随心所欲，没有计划，想到哪做到哪，其最终的结果是失去控制。那种认为只要产品做出来可以运行，何必花费许多精力去做文档的观点是错误的。经过实践，我深刻体会到，没有文档会带来很多问题。我认为文档应该是开发中每段时间的里程碑标志，每个阶段后都要提交相应的文档，这样可以用文档去引导开发过程，从而抛弃随心所欲的开发模式。
确保文档质量的最有效方法就是评审，提交文档后，组织相关人员对该文档进行审核，在充分讨论的基础上进行文档的重新修改和审核直到满足项目要求。在不同的阶段，需要不停地对文档进行完善，使之真正成为贯穿整个过程的主线。
问题管理
在开发过程让我感受非常深刻的经验是，每个人都需要知道出了问题应该找谁。我们在开发过程中不可能是一帆风顺的，不时地会遇到各种各样的问题，而如何解决问题，或者说是如何想办法尽早的解决问题，这个才是关键。而其中的最关键是不能有了问题而一声不响，闷头苦干，结果几天下来以后，却发现自己还是站在原地，而就算是你通过了几天的努力完成了这个难题。但是这样就是不是意味着你的成功了呢？
这样不但自己的进度没有办法完成，更会延误了整体的开发进度，别的成员就可能因为你一声不响地没有成果的努力，而不能再继续下面的开发。应该说软件开发过程中遇到问题一声不响、埋头苦干的做法是很愚蠢的，软件开发要求的不是个人英雄主义精神而是团队的整体合作精神。缺乏团队的意识的个人和团队必定是一个失败的开始。
就开发人员而言，一旦碰到了难以解决的问题，不仅要自己努力调查，想办法解决，一方面也要把存在的问题向PM反映，让PM能够知道存在的问题，而PM可以在进度会议、或者召开临时紧急会议，把问题摆出来，通过大家来寻求解决的方案。一个人的力量毕竟是有限的，而个人的英雄主义是团队开发的极大阻碍。
四．痛苦的进度管理
正如夏日的太阳一样，一直在灼烧我的心的是对进度的控制。进度管理是软件开发中最难以做好的一项工作。编程工作本身是一个难以量化的工作,再加上开发过程中对设计的修改等因素,使得项目开发工作经常不能按预计的时间完成。
开发人员最担心“领导不断催促，可系统提交日期一拖再拖”，项目负责人对此一筹莫展，束手无策。开发活动如同一个黑箱子，资金扔进去了，人员扔进去了，设备资源扔进去了，但不知道什么时候会出来结果，更没有把握出来的东西是否是用户所要的东西。
为避免人力、物力、财力浪费，就要进行有效的时间进度控制。在进度管理上主要有两点，一点是总体进度，另一点就是个人进度了，而总体进度是建立在个人进度的基础上的。
很多的人可能会以为，进度管理就是leader或者说是项目经理的事情，而与团队的其它开发人员毫无关系。其实，我认为这样的认识是非常的错误的，开发人员和所有过程都应该是有关联的。总体进度应该由PM来控制和调整，而个人进度却是软件开发人员个人的责任和职责所在。很多时候开发人员可能会抱怨，开发时间本来就少，每天又让我们写这种毫无意义的个人进度报告，这样就会浪费更多的时间。
其实不然，没有良好的进度控制管理，拥有再精英的团队也是白搭。开发人员在很多时候都是站在自己的出发点进行思考，相互间的沟通也只是个别人员之间的交流，并不能从根本上把握全体进度，也无法对进度作必要的分析和调整。而开发成员的个人开发进度报告汇总以后，能够让PM清楚的知道什么地方存在着问题，从而从项目整体上调整进度，决定相应的对策。
我的做法是每周将项目进度情况与项目进度计划进行对比。对于拖延的工作如无充份理由,我则会督促有关人员加班或提高工作效率赶上进度。如有正常理由,在无法追回的情况下就可以修改进度计划。在这里，我建议在软件开发的过程中，不管项目的大小我们都应该抽时间来写一份个人的进度报告，而在个人进度报告上应该有清晰的个人进度，存在问题，准备如何解决等等记述。总之，一句话，报告要简明扼要能够清楚地反映个人的进度状况以及存在的问题。
同时个人进度管理也是开发人员的自我管理，是进度控制的最重要组成部分。个人进度是总体进度的基础，个人进度的状况好坏直接影响到团队总体的进度推进状况。
五．配置管理的重要性
在项目取得一定进展的时候，我们会为之兴奋。在这里我想说说对配置管理（Software Configuration Management）的看法和理解。配置管理简单说可以是版本控制管理，但配置管理并不仅仅是版本的控制管理，还应该涉及到代码协调、履历追踪、品质检查等等细节的问题。
为什么我们要在软件的开发过程中引入配置管理？其实不为什么，在前面我也曾经提到过，软件的开发是团队行为，是合作，而不是个人英雄主义的自我表现。配置管理就是对软件开发过程中的产品（这里是说产品，而不是代码，因为我们的软件开发还包括各类文档，会议记录等等）进行标识、追踪、控制的过程，目的就是为了减少一些不可预料的错误，提高生产率。
一般来说可以使用配置管理工具来提高效率。例如常用的有VSS和CVS。一个好的配置管理工具应该具备这样的功能：一是并行开发支持，要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制。二是履历管理，也就是修改的历史记录的可追踪性。能够明确地知道什么时候，谁作了什么，为什么怎么做。从而达到管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。
结束语
最后，我建议对项目开发中容易出现的问题，项目组内部应该举行技术交流讲座。每一两周搞一次内部的Tech Talk或者Chalk Talk。让组员之间分享技术心得，这比花钱送到外面去培训划算。
在这次作为开发负责人中，我学习到在开发过程中必须处理好四个关键问题，这四个关键问题为：人员沟通、规范、测试、进度控制。只有严格把关，才可以大大提高软件的质量。