【原创】项目生命周期模型（付个人观点的解决方案）

转载请注明出处 http://blog.csdn.net/koangel

一、前言

以下内容为小弟拙见，喷者见谅。

结合小弟经历过的诸多项目发现，除了本人有能力主导的项目外，基本上均无正常按期完成产品。

所以有了诸多想法，诞生此文，结合《软件快速开发》理论，得出以下分析内容以及猜想。

二、风险分析（进度风险以及问题）

风险往往是可在产品开发初期即可避免的问题或习惯，如果我们无法合理的再开发初期规避问题，那么将导致开发的延期以及无法控制的地步，往往会导致成本估算成为完全不可信的。

以下是作者在产品过程中所遇到的问题以及其问题分析的原因，在软件快速开发中，我们称其为风险分析：

1、缺乏设计，鲁莽编程

产品的设计者（游戏策划，项目设计者等），对设计的内容并无任何的规划便开始直接编码或开发人员无基本的UML设计开始编码，在编码完成或接近完成时发现不符合设计规格或策划要求，那么你的项目风险将极其的大。

解决方法：再次我们可以回到正轨的项目进度上，从发现错误时开始，将模型生命周期切换为渐进原型或阶段性交付，从现在开始对项目的设计进行规划并且开始迭代产品的设计文档，在设计阶段规避问题，采用阶段性交付模型，将产品以模块的形式逐步交付最终完成最终产品，那么我们的重点在于如何迭代产品的设计文档以及在编码阶段不再提出以及插入新需求，对目前需求进行详细的规划，基本上可以回归产品的正常进度。

2、产品镀银

产品镀银的问题在于，将在需求中加入大量无关紧要的功能，但大部分功能开发周期较长。

解决方法：最好可以在产品的设计阶段意识到哪些功能和模块意义并不大，可以采用其他方式对其进行替代，这样的方法可以快速的结束产品的迭代，同时使设计人员意识到开发产品的成本以及时间周期并不容易掌控，其实在目前来说大部分组织可以将时间的评估成本控制在10%误差内，很少控制在5%以内的。

3、产品进度过度乐观

通常情况下，大部分开发人员以及PM对于进度都是很乐观的，因为乐观的进度往往可以鼓励团队的开发人员，但是诸位乐观最好是有个限度，如果过度乐观往往会导致其评估数据的偏差极大。

解决方法：采取大量的数据评估，尤其在进度评估时，请使用最合理的数据评估，尽量以悲观数据作为参照模型并且在鼓励团队成员时可将悲观进度描述为乐观进度，这样在某些情况下可避免大部分问题所导致的时间拖延。

4、团队成员流动性过大（尤其是主要成员）

我们经常会看到很多团队对于人员的意识实际是很薄弱的，举个例子在部分韩国公司的网游产品开发周期中会大量更换其开发人员，以便节省成本，但是其节省成本的目的导致其源码质量极差以及产品时间延误，原因是新进的开发人员需要时间熟悉上个开发人员所遗留的代码，同时每个人的风格导致大量的代码重写（并非重构），这类问题会导致进度完全无法掌控，在厉害的PM也会因为这种事情导致进度延误，所以尽量避免团队成员的更换是非常有必要的。

解决方案：尽量保证开发人员的利益以及其目标一致性，同时尽量保证新进开发人员不去对旧代码进行重写或重构保证其延续性可以减少开发成本，可以在后期将重构纳入开发进度中，从而缓解部分系统产生的问题。

5、合理区分重构和重写

重写与重构最大区别就是重写将代码75%以上进行完全的修改或删除，使其变更巨大，拙劣的重写往往导致其接口的变动，从而影响其他系统，如果是底层代码，往往会导致巨大的修改时间。

重构是保留大部分以前的代码，尽在结构，模式等方面进行修改，使其更具有阅读性以及维护性，重构往往不会大量影响其他接口，保持小范围的修改以及结构变动。

7、没有采用SCM（软件配置管理体制）

在软件开发中，我们往往会忽略SCM的重要程度，尤其是对于版本控制系统的忽略以及项目管理中未提及的SCM体制，通常情况下会导致源码的安全性无法保证以及协同开发性的问题。

OK，SCM仅仅包含版本控制器么？NO，SCM是庞大的一套体系，它的目的是保证软件开发过程中是安全的，可靠的不会存在丢失问题或错恢复机制，而其中比较代表性的就是版本号管理，版本控制器，文档管理以及资源管理制等，所以安全性往往保证软件的开发过程中毫无后顾之忧，请保证自己的产品拥有SCM体制。

8、细致的功能列表以及文档

开发过程中，我们往往发现任务并不细致，为什么？原因可能有很多，大部分情况问问自己，其实你明白需求么？尤其是项目的管理者，如果你都不懂需求，那么在先进的项目管理模型对你都是没用的，因为需求修改的可能性非常大，所以细致的定制功能列表是非常重要的。

在开发过程中细致的定义功能理解可以编译开发人员理解产品的内容以及分析需求，从而设计UML以及其系统模型。

先写这么多，睡觉了，呵呵呵