我的项目管理模型

说道项目管理很多人都会想到pmp，并且想当然认为知道了一点pmp就掌握了项目管理的金演出钥匙，其实不然，我也学了一点pmp，发现如果想把pmp直接使用到项目是有非常大的问题，主要体现在：

1、pmp太过庞大，如果什么都按它那一套来估计国内很多中小型软件公司都要关门大吉，因为形成文档、人员配备、流程审批等等这些都要消耗掉很大成本和时间。

2、pmp并不是专门针对软件开发的，有很多本来需要深入探讨的，没有说的太清楚。

        当然除掉pmp之外还有迭代式开发、xp开发现在也比较火，不过这些开发模式都有点问题，特别到了中国以后迭代式开发、xp开发编成不控制需求、不写文档、不设计程序的挡箭牌。其实从项目管理本身出发我们不应该追求pmp、迭代、xp，而是应该针对各种类型项目分别形成一套自己的管理模型，在项目开始或过程中根据项目特点选择对应管理模型进行管理，并且通过理论学习和经验总结不断完善自己的管理模型。一个管理人员只有这样管理水平才能不断增减，项目管理才能如鱼得水。废话少叙现在介绍一下我的一个vc项目管理模型，下面将从环境要求、需求管理、设计管理、编码管理、测试管理、进度管理、风险管理等七个方面进行说明。

 

环境要求

1、需要一台专门电脑作为服务器。

2、在服务器上搭建svn代码管理平台

3、在服务器上安装类似bugfree那样的软件用于bug管理

4、在服务器上搭建一个自动构建平台，每天自动从svn上取最新代码、自动构建、并且根据svn版本自动产生版本，如果在构建过程中发现error、warning将进行记录。

5、在服务器上搭建代码自动检查，包括圈复杂度、注释量、代码是否规范等

7、在服务器上搭建需求管理服务器，用于对需求进行管理，如果没有就用excel管理就可以了。

6、在服务器上搭建开发任务管理服务器，用于对开发进度进行管理，如果没有就用excel管理就可以了。

 

需求管理

   需求是软件的核心部分，也是外面各种教材、方法论最多的一部分，就需求调研这一个部分就能讲很多。如果要把需求完全文档化能够写《需求调研》、《用户需求》、《需求规格》等好多文档，但现实中如果项目不是很大搞这么多文档则没有必要，因为需求做的多么完美后面都会有一些修改，如果文档过多后面的维护也挺痛苦，并且按理论上要求用户、需求分析人员、项目经理每个文档上的每个需求都要对应，这个对很多人来说是很难办到的。一般情况下使用excel建立一个需求列表文件进行需求管理就可以了，其格式可以如下：

 

编号	内容	状态	级别	预估工作量	开发已投入工作量	测试已投入工作量	备注
1	通过命令行的方式对两个xml文件进行比较，并以xml+xsl的方式输出比较结果，命令格式如下"/file1:xxxx  /file2:xxxx"	已完成	5	50	30
2	1、记录曾经成功打开的历史文件路径 2、记录最新保存的文件路径 3、根据时间顺序排列已记录路径，最新打开或保存的文件路径记录在最上面，文件路径最多只记30条	处理中	2	12	20
3	客户方原来已经有一个权限管理服务器，要求软件能够连接到该服务器，从服务器上获取权限，然后根据权限实现对各个功能访问的控制	已废弃	-	30	14		因为客户原来的权限管理服务器不允许第三方软件连接，所以该需求停止实行。

  通过定期对需求列表文件的查看、维护和更新可以很方面的对需求进行管理，对每个需求已投入工作量的统计也非常方便。

 

设计管理

       程序设计的好不好将直接影响到功能实现的难易程度、代码的可维护性、软件的可测试性以及与其它系统的兼容性，一个不合理的软件结构将会为项目管理埋下很多隐患。所以为了保证软件的质量和项目进度，必须对软件设计进行管理。在对软件设计进行管理的时候首先对设计工作进行分类，针对不同类型的软件设计采用不同管理方法。

 

1、新系统设计管理

     需要技术人员和需求分析人员一起 对系统架构、开发成本、开发周期和技术难度等进行综合评审，通过以后才可以编写代码。

 

2、原系统核心组建优化设计管理

     如果是对原来系统的部分核心组件进行优化，则作为管理人员首先要检查修改组件的理由，如果理由不充分则要停止修改行为，只有非常必要的时候才允许对核心组建进行修改。

     如果一旦决定对核心组件进行修改则可以交给设计人员设计修改方案，如果有几个方案设计人员都可以列出来。在方案设计完成以后，可以组织相关专家进行评审，根据成本、时间、技术难度、风险等选出一个比较好的修改方案。

      在修改方案确定以后则交由设计人员设计方案实现细节、写出算法，完成细节设计以后则组织专家、开发人员对整个设计方案进行评审，评审通过以后才可以对核心组件代码进行修改。

3、小需求修改设计管理

     不需要专门的评审，开发完进行代码review就可以了。

 

编码管理

        “千里之堤毁于蚁穴”，代码上一个很小的错误就可能造成整个系统的瘫痪或崩溃，任何健壮的程序都是建立在质量良好的代码上，所以编码管理是保证软件质量的首要任务。不过能够把编码管理做的很好也并非易事：这个主要是因为虽让大家都知道代码质量很重要，但是在大部分项目的领导和用户只关心功能是否能够尽快实现、能否看到东西，而没有给保证代码活动预留时间；还有程序员也喜欢天马行空、标新立异，并且当统一规范限制他行为的时候就绕开或直接抛弃规范。故从需要以下几个方面对编码进行管理。

1、首先是提高公司领导和用户对代码质量的重视程度

       要向公司领导和客户说明不给单元测试预留时间会带来哪些风险，介绍高质量代码会给公司和客户带来哪些收益。

 2、根据项目特点制定统一的编码规范、并对项目组成员进行宣讲

        编码规范有很多种，他们之间也没有所谓的谁比谁好，只需要选择一种大家都比较认可的就可以了。在确定了 编码规范要向大家宣讲，对新员工要进行培训。做的比较好的也可以安排考试，保证大家对规范的内容都非常熟悉。在制定规范的时候最好也确定一下最大圈复杂度和注释量下限。

3、实现一定程度上的结伴编程

        如果在编写代码的时候如果一块代码只有一个人负责则在编码风格、算法优化、结构合理性等方面很难做的很好，因为再好的程序员在思维上都有误区或偶尔的错误，当然通过培训和考试能够改善很多，不过最直接的方法还是结伴编程，任何一块代码由两个人负责，这样不但能够保证代码质量还能促进相互学习。

         当然如果采用两个人对着一台电脑编程的方式可能成本太高，我们采用的是一定程度上的结伴编程。即项目组内每两个人结成一对，在写代码时候每个人实现自己部分功能，每个人检查自检代码没有问题以后就提交到svn服务器上，并通知另外一个人可以对其代码进行检视，对方在规定时间内抽出时间帮助检查，并把发行的问题记录在《代码检视表》中，对方完成代码检视以后通知代码编写者，代码编写者根据《代码检视表》修改代码，但如果有不懂或有分歧的可以再协商讨论。

4、代码自动检查和人工检查相结合

        为了保证代码质量要求程序员在向svn提交代码之间必须先进行代码自检，代码构建服务器也会对代码进行检查并输出报告，项目经理要每天查看输出报告，对于编译出现error、warning的要求程序员立马修改，防止影响别人的工作。对于最大圈复杂度这些不达标的则要求程序员限期修改。当然使用工具检查也不是万能的，有的程序员为了应付代码检查工具把代码质量搞的更低，所以代码也要和人工检查相结合。在我们这里是通过结伴编程方式解决的。

 

测试管理

        测试管理即为对测试和开发人员的所有测试工作所进行的管理，具体包括单元测试、集成测试、系统测试。其中单元测试和集成测试是由开发人员完成，系统测试是由测试人员完成。当然这个也不是绝对的，有的公司资源比较多或者对程序稳定性要求比较高也会让测试人员写单元测试，但这个对测试人员要求比较高，中国很多公司达不到这个要求。

1、单元测试

        在整个测试管理中最复杂、最困难的是对单元测试的管理。因为一方面单元测试技术含量比较多、重复性工作比较多；另一方面开发人从自己内心来说不相信自己代码有错误的，并且认为单元测试代码一般开发完了以后就会扔掉；再者单元测试确实要花费很多时间，程序代码更新以后对应单元测试代码也要更新，而我们很少给开发人员足够的时间。关于单元测试这一块管理很好的公司我现在还没有发现，很多大公司虽然指标都有，看数据也达标了，但具体分析一下单元测试代码，你会发现都是一些毫无用处的东西。

  所以为了避免出现这种问题，我们要求先分析一下哪些部分代码是需要写单元测试的，对一些非核心代码、界面性的及经常改动的代码不强制要求编写单元测试。对于核心代码、算法比较复杂的强制要求编写单元测试，给编写单元测试给出预估时间，通过结伴人员相互审查保证单元测试的质量。

2、集成测试
      关于集成测试其实在所有项目中所有开发人员都在有意或无意的在进行着，比如我开发完一个功能用鼠标点两下看有没有问题，不过这种测试的质量怎么样是完全没有办法度量的。不过如果完全按照教材上说让程序员先写一大堆测试用例，再评审，再测试这样流程走会非常耗时，因为让开发人员写测试用例很多人都有抵触情绪，并且一时也很难想到很多用例，最后为了赶时间、拼数量就写了一堆同质的用例。

       对于集成测试要解决的最大问题就是怎样让测试文档化，变成可度量的。所以在我们项目中采用随时记录的方法，首先我们制定一个《SDV测试用例表》，发给开发人员，开发人员在开发完一个功能以后如果他要简单测一下，就顺便把当时怎么测的记一下。这样在软件所有功能开发完成以后集成测试情况一目了然，不过为了保证集成测试质量，开发人员的结伴人员要在规定时间范围内对集成测试用例进行审查。

3、系统测试

     而系统测试最大的问题是测试质量，因为在国内大部分软件公司里测试人员水平一般都比较低，做过开发的基本上没有，就是测试经理能够知道开发的也是凤毛麟角。很多测试人员比较关注界面友好性、提示语是否正确这些问题，而对依赖的软硬件环境、复杂业务逻辑、配置文件、通讯、数据库等出现异常、需求完成度等测试的比较少。在很多测试人员的测试用例中同质性问题比较严重。

      为了解决系统测试中的问题必须对测试人员的测试用来进行管理。在测试中我们要把测试分为功能测试、复杂业务测试、软硬件环境测试、异常测试四个部分，测试人员首先完成功能测试的用例编写，其格式如下：

编号	用例名称	预置条件	操作步骤	预期结果	测试结果	备注

      功能点就是《需求规格说明书》中的每个需求。在完成功能测试用例编写以后要进行评审，确保需求中所有功能点都覆盖到。在完成功能测试以后，就需要编写复杂业务测试用例，复杂业务测试用来是通过功能测试用例组合而来，其测试用例可以如下：

用例名称	操作	测试结果	备注
购书中止	1、2、3、4	pass

完成复杂业务测试复杂业务测试以后也要进行评审，复杂业务测试用例完成以后就可以编写软硬件环境测试用例和异常测试用例，硬件环境测试用例和异常测试用例一般是假定哪几个软硬件环境和异常情况，运行哪些功能测试用例来实现

环境	操作	预期结果	测试结果	备注
电脑内存2M 硬盘4G	3、5、6	运行正常
通讯过程中网络中断

当然如果是大数据量和响应速度要求比较高的还要写压力测试用例。

 

进度管理

          在我们项目开发过程中经常发生开始一直捷报频传、项目组其乐融融、项目经理信心满满，但到了认为只剩下10%的时候就会产生各种各样问题，需求实现不完全、改不完的bug、客户不满意、项目组之间相互推卸责任、项目经理看谁都不顺眼，最后轻者项目延期、重者项目失败。为什么是这个样子？这是因为我们项目管理人员没有了解到真实的项目进度，只是听程序员、测试人员的汇报而没有去核实，也没有对代码质量、测试用例质量进行度量和检查，所以进度管理最重要的是了解项目真实的进度。
 

 风险管理

        任何项目都有风险，特别是软件项目。项目风险是多方面的即有需要变更、工作量预估不准确、资源不到位、也有人员不称职、开发过程中人员离职、核心技术问题无法解决等原因，并且在开发的不同阶段每种风险的大小是不同的。为了加强对软件风险的管理我们需要使用excel制定《风险管理表》，格式如下：

描述	状态	级别	处理记录
最近一次加薪核心成员A没加，A非常有意见，多次提出要离职	处理中	5	2010-11-3有一次谈话，但A还是要离职
B模块圈复杂度偏高，开发进度比计划的慢	未处理	2
用于测试的路由器设备还没有到位	已关闭	2	与路由器设备供应商沟通以后路由器已经送到

        在风险管理表制定以后项目经理要每周必须对每个风险检查一次，对风险的状态进行修改，并且新发现的风险要及时添加到《风险管理表》中。