超实用！项目生命期各阶段的管理总结（项目生命期的各个阶段）

软件项目经常遇到的一些问题可能包括：项目时间紧、项目组成员经常加班；项目需求变更频繁；项目进行过程中可能就有项目团队成员离职或调离到其他项目组；项目重复性建设问题严重，每个项目都需要从框架开始重新开发，难以重用已有项目的成果等等。我觉得通过较好的规划和管理能够在一定程度上提高项目的成功率或者说提高项目的质量，降低开发成本，缩短项目开发时间。

我理解项目管理有两个大的划分方法一是通用的项目管理体系，也就是PMP中所说的五大项目管理过程组10个知识领域49个项目管理过程；二是具体业务领域的按项目生命期划分的各阶段的管理。本文主要从项目生命期各阶段的管理方面进行总结。

软件项目生命期大体需要经过的流程：可行性分析、需求、设计、开发、测试、实施、维护、总结。

一、可行性分析

一般的项目都是通过外部招标的形式得到的。对于有些公司在竞标的时候对项目就要有个取舍。如果在特殊时期为了生存可能只要不是太赔钱的项目都会尽量承接。

但是一般项目在承接前最好在经济、技术等方面进行可行性分析，而且这种可行性分析最好是管理者、市场、技术等人员都参与，因为市场人员一般不太懂技术，，因此只有大家在一起共同分析讨论才能够得出比较可行的结果。可行性分析的结果一方面可以作为是否承接项目的依据，另一方面也可以作为承接项目的方式或与客户谈判的依据。比如经分析项目工作量很大，如果按标书金额开发有可能会赔，那么可以与用户探讨是否将来能有个二期的项目；另外如果用户要求的时间比较紧，可是经分析很难按标书时间完成，那么也可以和用户同共探讨是否可以在正式签定合同时延长系统交付时间等。当然这些与用户的探讨工作一般是需要公司高层领导出面协调的，有时单独靠项目组是没有能力达成理想的结果的。

另外在此阶段最好对项目的成本和需要的资源进行一下估算。

二、需求

需求实际要细分为需求调研、需求分析、需求确认、需求管理等。

如果早期需求做得不够仔细会给项目的后期工作带来很多的隐患。

我建议每个项目无论多大也无论项目时间要求多紧急一定要有一个比较详细的需求文档。

在需求确定之后再对项目成本进行估算。同时对需要的资源及相关里程碑进行说明。

三、设计

大部分中小型项目会因为时间和人力的问题加上需求变更比较频繁，所以有时很难书写一个比较详细的设计文档。但是如果没有设计文档一是为后期维护可能会带来一些问题，尤其是当原来开发人员或主力开发人员离职或调离到其他项目组时；另外没有经过详细设计的项目可能也会存在一些风险。

因此建议不必为了文档而文档，除了项目验收的要求外，建议设计文档根据项目特点有选择地包括以下一些内容的说明：

超实用！项目生命期各阶段的管理总结（项目生命期的各个阶段）

系统的关键配置说明（如数据库服务器，应用服务器等等，如有必要可另加附件进行说明）。

对于中小型项目如果不是用户要求有时不必在设计文档中对所有数据库表及字段都进行说明，可以只说明比较重要的一些数据库表及字段以及相关数据库的关联关系就可。因为在用数据库建模软件进行数据库设计的时候可以对每个表及每个字段加注释进行说明，在使用开发工具进行开发的时候自然可以看到每个数据库表或字段的说明。而且一般中小型项目在开发的过程中可能需要经常性地修改数据库表的设计，如果还有文档描述数据库的设计那么每次修改时除了修改数据库之外还要维护设计文档的一致性，如果项目忙忘记了修改就会导致文档和数据库的不一致，有时这种不一致的文档可能还不如没有，因为它可能会误导其他人员的理解。

另外也可以通过开发过程的规范来减少设计文档的内容。这个将在下面的开发环节进行详细的说明。

四、开发

整个项目有一个合理的框架是很重要的。框架具体包括哪些内容在此很难解释清楚，但是我想最起码整个框架应该把项目所采用的各种技术（如java中的Hibernate、Struts、Spring的结合）比较合理地组织起来，并为具体模块的开发提供一些工具类等，同时整个框架应该具有较好的可扩展性、可维护性和较好的性能。框架最好由项目组中技术最强的人（在此称他为技术负责人）进行搭建及维护。

另外对于整个项目有一个统一的命名规范（类和方法按什么方式命名，所有文档都加上时间作者等）并进行遵守是很必要的，这样一个人开发的代码其他人很容易就能够读懂。

在整个项目进行全面开发前最好先向项目组全体成员讲解需求及项目框架的机制、使用方式及注意事项，再说明相关规范。然后每一个开发人员按照理解开发一个简单的功能。然后大家在一起（或者由技术负责人）看一下每个人对于框架的使用是否合理，规范理解的是否有误，编码习惯是否需要改正等等。在讨论并达成共识后再进行具体功能的开发。另外在具体的开发过程中尽量在关键算法处加一些注释进行说明。建议定期进行一些代码走查的工作。尽量由技术负责人负责这份工作，当然也可以进行互相检查等。代码走查的好处很多，如何发现一些不好的编码习惯；提高整个系统代码的可读性；发现一些bug；借鉴别人好的编码思路或技术等。

五、测试

首先开发人员一定要养成单元测试的习惯。对自己开发模块的功能进行单元测试过之后再提交测试组进行结合测试、系统测试甚至性能测试。单元测试很重要，在进行单元测试的时候如果条件允许可以使用一些代码覆盖率工具帮助分析测试用例的覆盖程度。另外，一般项目可能是整体开发完之后才进行性能测试，可是这时测试出性能问题了却因为临近上线或试运行时期，不一定有充足的时间进行修改，另外也可能因为整个项目已经都使用了某种影响性能的技术或方法，要想改变要付出很大的代价。所以建议如果条件允许可以在开发的过程中（甚至搭建项目框架时）使用一些轻量级的开源性能测试工具由开发人员对可能影响性能的功能进行测试。

对于测试部门的测试人员要尽早地参与到项目中来，建议在需求阶段就介入。早介入的好处一是可以对需求理解得比较深入，知道原始需求是怎么来的，中间经过哪些变化，这样会比在开发结束后一次性地讲解能够更好地把握需求，更好地书写测试用例及测试计划。

项目组设计人员一定要把一些关键测试点、数据及功能的关联关系对测试人员说清楚。测试过程中有一个bug管理系统并对bug进行跟踪是很必要的，最好是在项目结束后能对产生的所有bug进行一下分类。然后通过分析得出一些规律。通过在以后的项目中采取一些措施进行项目质量的提高。

六、实施

对于涉及多个子系统的长期开发项目，在系统设计和开发过程中要优化处理关联性强的系统，同时有一个（或几个）系统成熟了就试运行或上线，不必等所有系统都好了再上线。一是因为时间长了开发人员可能调离至其它岗位，维护代价会增大；二是子系统用户可能会改变而导致需求变更；三是时间长了用户对系统需求会有陌生感，也可能会产生新的需求；四是时间长会打消用户对使用系统的积极性；五是较早地让用户看到系统也可以减轻因双方理解偏差而导致的系统需求变更的影响。

七、维护

争取把用户提过的所有修改都进行记录，并争取所有修改都请用户签字（不一定提一个修改就签字一次，可以统一记录然后定期把一段时间内的修改进行签字确认），如果做不到所有修改都签字也尽量做到对于重大修改请用户签字。签字的好处很多：让用户看到项目组所做的工作；如果修改的内容比较多可以通过双方高层领导的沟通再进行系统二期或三期的开发；有了签字有时用户对需求变更会相对少一些等等。

另外对于所有修改除了签字留档外争取定期把所有修改的内容再整理到需求文档中，保持需求文档与正式环境功能的一致性。这个工作很有必要，可能带来以下一些好处：方便测试人员在回归测试时理解系统功能；如果维护人员的调离其他接手人员比较方便理解系统功能等。

八、总结

建议每个项目结束后都召开一个项目总结会。项目总结会建议与项目相关的所有人都参加。由项目经理进行主要总结，但每个参与人员最好也都进行总结。可以从管理和技术两大方面对项目中的每个阶段的成功与失败进行总结，目的是总结经验教训，提高每个人的项目经验，提高项目组的成熟度，使以后的项目更加成功。在此要强调一下，一般项目总结时大家都喜欢只说成功的，而很少提到失败的或所走的一些弯路，而往往对这些失败的总结更能使大家收获更多，当然这也要看组织的文化，我建议如果可能尽量鼓励大家多总结一些失败的经验教训。

项目结束后如果有时间最好是把项目中的一些有重用价值的文档放到公司的组织过程资产库中。

如果项目的框架比较合理也可以剔除项目中的业务相关功能的代码，整理出项目框架并加以简要说明文档供本项目组其他项目或其他项目组使用。

九、项目经理职责分析

对于中小型规模的项目，项目经理可能既要充当管理人员的角色又要充当开发甚至实施人员的角色，基本上软件项目生命期的每个阶段都要参与。

但是我觉得以下一些工作项目经理一定要重视：

超实用！项目生命期各阶段的管理总结（项目生命期的各个阶段）