前言：现在的市场上充斥着各种各样的关于软件项目管理的书，我不大喜欢看这一类的书本，一方面这些书本都是国外书籍的中译本，有的地方翻译的可能也不是很符合中国用语的习惯，看起来可能会觉得难于理解(大量的晦涩英文学术专用语，不翻译也就算了，翻译过来了就完全不知道在说什么了)，枯燥乏味，二来也觉得看了也不是很实用，所以我个人不大看这一类的书。

　　经过几年的磨练，从编码开始终于稍微的了解到了一些软件项目管理的具体内容，以及软件项目管理实施步骤，如何实施。以我个人的理解总结了下面几个部分。

　　一.需求管理

　　客户需求管理

　　天大地大，需求最大。对于我们软件开发人员来说，客户的需求也应该是最大的，不仅仅因为客户是我们的衣食父母，也是我们软件开发人员成长的催化剂。我们不是End-User，所以有的时候关于某个特定系统上的具体细节可能是我们没有办法考虑到的，是在我们的领域里可能没有办法想象得到的，这个时候我们就必须要通过实际应用系统的End-User，也就是我们项目的最终客户来了解具体的客户需求。对于一个缺乏需求管理的软件项目而言，必定会导致系统不能实现预期的功能而需要在后期进行昂贵的修正，使得项目拖期、产生严重的质量问题与超出项目预算的现象。

　　了解了客户的需求，可以让我们在软件的开发过程中少走很多的弯路，缩短软件开发的周期，了解了客户的需求，能够提高软件的友好性，易操作性，易用性，从而来提升软件的质量。

　　需求成本管理

　　对于客户的需求，我们要尽量地予以满足，但也不是一味地不顾技术实现上的困难而迁就客户的无理要求，在需求管理进行的同时，我们也不能忽略了成本问题。因为每一个功能的实现都需要我们花费时间去努力的。做需求管理的人员要和客户进行很好的沟通，在成本和需求之间找到平衡点。这些话说起来是很轻松的，做起来是绝对的不轻松，面对客户你必须要保持涵养，而你说面对的客户可能是一点都了解什么是软件，或者说是我做这个东西需要多少人力物力，而需求管理人员就是要对客户的需求进行必要的补充说明(基本上应该站在为减少成本，提高质量的立场上)。

　　需求内容传达

　　而在有了具体的需求以后，然后需要和我们的软件设计人员进行沟通，务必做到使他们清楚地知道客户需要什么，确定我们的航向。概括所以在项目管理的组成中，需求管理的位置是很重要的，他们有着桥梁的作用，接通了客户需求和软件开发之间的道路。

　　二.进度管理

　　在进度管理这个呈面上其实有两点，一点是总体进度，另一点就是个人进度了，而我们的Project 进度却是建立在个人进度的基础上的。

　　很多的人可能会以为，进度管理就是leader或者说是Project manager(PM)的事情，而与团队的其他开发人员毫无关系，其实，个人认为这样的认识是非常的错误的。开发人员和所有过程都应该是有关联的，并不存在着什么什么是某某人的事情这样的说法。

　　总体的进度应该由PM来控制和调整，而个人的进度却是软件开发人员个人的责任和职责所在，有很多时候软件的开发人员可能会抱怨，在原有工作时间段里，开发的时间本来就少，每天又让我们写这种毫无意义的个人进度报告，这样难道不是浪费了我们更多的时间吗!

　　其实不然，一个精英的团队固然重要，但是没有良好的管理和沟通，统筹全局的管理，那么拥有再精英的团队也是白搭。开发人员在很多时候都是站在自己的模块里，或者说是以自己出发点进行思索，他们之间可能存在着相互间的沟通意识，但也只是个别人员之间的交流，并不能从根本上把握全体进度，也无法对进度作必要的分析和调整。而开发成员的个人开发进度报告汇总以后，能够让PM清楚的知道什么地方存在着问题，从而从工程整体上调整进度，决定相应的对策。

　　建议在软件开发的过程中，不管项目的大小我们都应该抽取0.5-1.0小时的时间来写一份个人的进度报告，而在个人的进度报告上上面应该有清晰的个人进度，存在问题，准备如何解决等等记述，总之，一句话，报告要简明扼要能够清楚地反映个人的进度状况以及存在的问题。

　　进度不是个人的事情，而是整个开发团队的事情。个人进度和全体进度只是着眼点不一样了吧。它所以反映的实质都是一样的，而个人进度更是全体进度的基础，没有了个人进度何谈全体进度。同时个人进度管理也是软件开发人员的自我管理，是进度控制的最重要组成部分，个人进度的状况好坏直接影响到团队全体的进度推进状况。

　　成本管理

　　作为PM不仅仅要把握全体的进度，更加要把握住开发的成本，如果开发的成本超过了，那对于我们的开发来说不能盈利，而不能盈利的开发也就意味着失败。

　　项目上的反反复复，开发人员加班费的支出，不仅加大了开发的费用，同时也给员工带来了身体、精神上的双重疲惫，直接导致个人抵抗力、免疫力的下降，更可能会造成员工身体上的隐藏疾病。同时也带动着相应的管理费用也随之增加了。这些都会使得我们软件的成本增加。

　　问题管理

　　问题管理其实是应该包含在进度管理里面的，但是它又有点特殊，所以把它单独拉出来了。

　　我们在开发过程中不可能是一帆风顺的，可能不时地会遇到各种各样的问题，而如何来解决问题，或者说是如何想办法尽早的解决问题，这个才是关键。而其中的最关键是不能有了问题而一声不响，闷头苦干，结果几天下来以后，却发现自己还是站在原地，而就算是你通过了几天的努力完成了这个难题。但是这样就是不是意味着你的成功了呢!不时的，这样的结果是不但自己的进度没有办法完成，更加延误了整体的开发进度，别的成员或者是小组就可能因为你一声不响地没有成果的努力而不能再继续下面的开发。应该说软件开发过程中遇到问题一声不响、埋头苦干的做法是很愚蠢的，软件开发要求的不是个人英雄主义精神而是团队的整体合作精神。缺乏团队的意识的个人和team必定是一个失败的开始。

　　就开发人员而言，一旦碰到了难以解决的问题，不仅要自己努力调查，想办法解决，一方面也要把存在的问题向PM反映，让PM能够知道存在的问题，而PM可以在进度会议、或者召开临时紧急会议，把问题摆出来，通过大家来寻求解决的方案。一个人的力量毕竟是有限的，而个人的英雄主义却是团队开发的极大阻碍。

　　三.配置管理

　　关于配置管理(Software Configuration Management-简称SCM)的概念在各类书籍中都能够看到，大部分的书籍都是从英文翻译过来的，而翻译书籍的人可能并不一定是和计算机学科有关联的，就算是也不一定在配置管理上有一定的经验。所以我想并不是每一个从事软件开发的人员都能够确切的理解它、把握它。概念的东西毕竟都是虚幻的，只有实际的运用了才能够变成自己的东西。

　　书上的定义我就不想说了，有兴趣的话大家可以去看书。我在这里想说说自己对于配置管理的看法和理解。配置管理可以简单地一句话说成是版本控制管理。而什么是版本控制，我想在使用计算机的人应该都会知道软件版本的概念，而我们的配置管理就是要对软件的版本进行控制管理。这个就是我们通常意义上说的配置管理了。而真正在团队开发中的配置管理并不仅仅是版本的控制管理，还应该涉及到代码协调、履历追踪、品质检查等等细节的问题。

　　为什么我们要在软件的开发过程中引入配置管理?其实不为什么，只是我们需要所以我们引入。在个人软件开发中只要你觉得你的水平够高，肯定不会发生Rollback，或者你只是在制作1+1=2这一类的简单程序时我想你也可能用不到配置管理。

　　在前面我也曾经提到过，软件的开发是team行为，是合作，而不是个人英雄主义的自我表现，不可否认在小项目上存在着个人软件开发，但是我想就算是个人软件的开发(简称PSP：Personal Software Programming-英文全称不知道是不是这样的，不大记得了)也不得不使用到配置管理。

　　有人把配置管理称为软件开发的一种艺术，以前在老外写的一本书上看到过，N多年以前的事情了，具体是什么书名已经不记得了。其实这样的说法也不算为过，配置管理就是对软件开发过程中的产品(这里为什么说产品，而不是代码，因为我们的软件开发还包括各类文档，会议记录等等)进行标识、追踪、控制的过程，目的就是为了减少一些不可预料的错误，提高生产率。

　　怎么做就是要用到一些软件开发过程中使用的配置管理的工具了。大概在七十年代加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后他又成立了一家名为软件工具的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，早期比较有代表性的有：Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。而如今我们最为常用的，且使用简单的要算VSS(Microsoft Virsual Source Safety)、CVS(Configuration Version System)了，此外还有一些价格昂贵、使用复杂的，比如：CCC Harvest、ClearCase等(需要一个专门的配置库管理员负责技术支持，还需要对开发人员进行较多的培训，可以说不适合我国的国情)。

　　VSS可能是国内目前使用的最多的配置管理软件之一，其实在国外很多的人都喜欢使用CVS。为什么，因为CVS是free的，而微软的VSS是要money的，为什么国内还是有很多人使用VSS，原因我想大家都明白我就不说了。

　　其实没有配置管理工具，我们手工也能对软件的配置进行管理，只不过很繁琐，浪费了大量的人力物力，所以我们使用配置管理工具，而要成为一个好的配置管理工具应该具备什么样的功能：

　　并行开发支持 - 要求能够实现开发人员同时在同一个软件模块上工作，同时对同一个代码部分作不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制。(对于这一点来说可能CVS比VSS做的更好，如果VSS不使用辅助工具SOS(Source Offsite)的话，那个公司或者是团队会把自己的VSS库共享到Internet上)。

　　履历管理 - 也就是修改的历史记录的可追踪性。能够明确地知道什么时候，谁作了什么，为什么怎么做。从而达到管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。

　　版本控制 - 版本控制中最重要的一个概念就是Rollback，能够简单，明确地取得软件开发期间的任何一个历史版本。过程控制 - 能够贯彻、实施开发规范，包括访问权限控制、开发规则的实施等。产品发布管理 - 软件开发过程中的一个关键活动是提取工件的相关版本，以形成软件系统的阶段版本或发布版本，我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始，而一系列定制良好的活动之后又会产生一个新的稳定基线。有效地利用此项功能，在项目开发过程中可以至始至终管理、跟踪工件版本间的关联。

　　本来谈一点关于VSS和CVS的配置和应用的，可是想想写起来会很多，而且还要贴图什么的，够麻烦的所以等以后有兴趣了再补上。

　　四.风险管理

　　项目管理中最容易被忽略而且是最难以管理的环节。在很多的情况下，许多人都不知道风险管理到底应该做些什么。其实风险是自始至终贯彻整个软件的开发过程的，没有一个做项目的team可以自豪地声称自己的开发没有任何风险。

　　什么是软件开发过程中所谓的风险，简单地理解可以认为是对软件开发过程中遇到的资金和进度等问题对项目的影响。风险的产生常常会使我们的进度迟缓，成本增加，甚至是软件项目无法实现。

　　我们可能无法根除风险，但是我们如果加强对风险产生的认识，对项目产生的风险进行有效的管理，就可以从最大限度上减少风险的发生，而这个就是我们风险管理的主题了。

　　面对风险的态度

　　很多的项目组可能不大注重风险管理，往往是到了风险确确实实地发生了，才回过神来开始面对，采取紧急的补救措施，试图能够快速的纠正，而这种被动的“救火”模式的风险认识存在着极大的危险，就是当对于风险的扑救失败以后可能会使得我们的项目处于水深火热之中。个人认为这种扑救的行为有点类似于寓言上所说的“亡羊补牢”。这种被动的风险策略是不可取的。

　　既然提到了风险管理，我们就要在风险尚未产生、形成之前，对风险进行辨识，并且评估风险出现的概率已经它们能够产生的影响，按风险有高到底排序，有计划地管理。这种做法正好和“亡羊补牢”式的被动风险管理方式相反，我们在这里采取了主动出击，就是这样做，我们也并不能从根本上防止未知风险的产生，我们能做的只是减少风险发生的可能，所以说风险的管理和我们的认知以及经验有一点的联系。

　　风险管理的要件

　　在计划项目书中写清如何进行风险管理。

　　在项目的预算中必须包含风险解决所需要的经费，已经它们可能产生的影响。

　　认识到风险在整个项目中是一个连续的过程，需要在项目进程中不断地进行。

　　风险管理计划(风险如何识别，量化风险，应对策略，风险监控)