目前实施项目规范的考虑  

由于目前软件开发实际情况的约束，完全按照RUP实施项目管理是一个理想化思路。在实际实施中会受多方面的影响（如客户要求、小组成员素质等），这种盲目的追求标准只会做成项目的阻碍，基于这种考虑，我认为根据实际情况采用分步实现的方式，逐步建立起一支稳定的、技术分工合理的开发TEAM，才能采?UP管理规范实现省时、合理的软件开发。

下面我根据自身对项目管理的认识，对原有项目管理中的问题进行总结，并对目前如何实现软件工程，及对本项目管理规范的实施进行了相应说明。
4.1. 对项目管理的几点感受

目前我们的软件开发多为瀑布式开发，项目管理可以说是没有。所有的管理与软件设计都是由项目经理一个人来负责，这样对项目经理的要求较高。项目开发主要依赖于个人能力，开发中又总是依靠程序员高手来支撑，好是要有一批“快枪手”。而高手又因为多种因素不能集中在一个项目中，同时高手的流动会给项目致命的打击。以上等等只是项目管理中的一部分问题。我对项目管理中之不足归纳为以下几个方面：

4.1.1.人员素质

项目开发人员的个人素质不同，根据素质进行角色与行为划分是项目管理中的一个非常重要的环节。

责任心

我在项目管理中曾遇过这样一种情况，有个项目成员技术不错，但是在开发的关键时期为个人的一点小事而不顾整个项目的进度，而其在项目中担任了比较重要的职务，在他看来，项目不如自己个人的小事（可做可不做）重要，所以造成项目进度的延误，我不得不去物色另外一个人来代替他。但后果已成。

还有一种情况，安排了某人工作，工作量在你的估算内，但是到了检查时，他对你说“我不会做”，“我不知如何做”之类的话，而同时他还在上网或做其他的事，但作为已有计划的你来说，则是项目进度被打乱的后果。

这种人当然在下一个项目不会被用，但是如何避免这种情况的发生呢？我认为应当将工作量细化到天甚至于小时，遇到这种员工则可立即开除，同时损失的工作时间是可控的。从而减轻了对项目开发的影响。

个人能力

程序员的领悟力各不相同。对不同的人要采用不同的方法来工作。

对个人能力高的人你可以务虚的谈工作任务，他在接受任务的同时可以提出这样那样的问题，甚至想到你没有想到的问题，直到把问题搞清楚。这样的人你可以放心的让他去做，因为他已经完全理解了你的意图。

对个人能力一般的人，你讲什么他不能理解的很清楚，有的为了面子不懂也不说，但是在做的时候出了问题，在你指着他做的程序大骂的同时，你的项目进度在拖延。对于这种情况，你只能写出对他工作的要求，写出你的意图，明确工作目标。

对个人能力差的人你不能说只是写个要求行的，那样的话他写的程序依然会让你忍无可忍，怎么办，把系统中技术要求较低的部分分出来，然后按1，2，3，4步骤写出来。有人说这样还不如自己写完算了，但是这种工作往往是重复量很大。如做界面等。

当然，RUP的实施方针希望是淡化个人力量，而注重流程与大家的协作，同时细化了系统的每一部分。但是的实施不能教条化，在实行中还要根据项目实际情况而变化。

自我约束能力

自我约束能力主要是指对管理者而言的。因为项目成员工作基本是由项目管理者来监督实施的，那管理者呢，可能没有人来管理，如果管理者的自我约束能力不强，那样建立什么样的软件工程规范都无法实施。

在实施项目管理规范时，由于条件限制，不可能一下完备软件工程所需的各个机构部门，从而也可能不存在与项目组平行的流程管理机构，质量审批机构等。由于采用逐步实现的方法，所以提高约束力只能采用其他方法。

针对这种情况，可以采用各种提醒方式：电子系统如掌上电脑；人员提醒如部门技术秘书等。

4.1.2.            工作流程

4.1.2.1             工作流程中的多重循环

用户需求的不断变化是令项目开发中头痛的问题了。我们在做项目时传统的做法是，新需求来了，赶快叫程序员们改，在这里加一块，那里补几行代码，只要实现行。结果是项目做完了，再看自己设计的系统已面目全非。还谈什么可重用性，可定义性，产品化，甚至下一个差不多的项目还要花费同样的时间。

RUP中强调的循环概念 是针对于这种情况提出的，通过项目小组之间各种角色的循环，实现对用户需求变化的问题解决。如下图

这样采用迭代法开发可以实现此问题，是的，但是要有所牺牲，那是时间。时间充足我们自然可以按照标准的RUP思路来进行。而实际上呢，又是我们牺牲不起的。现在国内大多数项目具有这样一个共同点：用户要求急。如我们做一个基金的核心业务系统，用户说开发时间为两个月。而由于基金是个新行业，无可用之部件，两个月的时间是不可能进行迭代开发的。同时我们还要在一定程度上避开需求不断变化。我建议采用的方式如下：

按阶段地进行循环

实现阶段性的循环，并且存在多个循环的并发。如业务需求循环在一个阶段内将生成相应的模型与业务需求文档，并得到用户的认可，然后转入系统需求循环，在系统需求转入另一个循环时，再继续业务需求循环，但此时只是记录用户需求，而不进行下一个循环。待根据初需求制作的版本生成后，再根据新的业务需求及与用户协商结果再决定是否开发下一个版本。

采用快速原型法

快速原型法的作用是为了让用户在感性上了解系统的概貌，通过与用户的交流，从而固定了相应的元素（如输入参数、跳转顺序等），通过快速原型法与用户进行交流，能很好的理解用户的意图与需求，是缩短开发周期的良好途径。

生成一个版本

用户需求是不断变化的，而且任意性很大，如果一个项目根据用户需求的变化而变化，那么开发周期是无法估量的。一个三个月开发周期的项目做了六个月，还没有一个象样的系统出来，用户则不断的埋怨开发力度不够，管理不好等，项目组又认为是用户随意性太大，导致了这种后果。结果是双方互不满意。

根据这种情况，我认为在业务需求循环到一个阶段，生成正式的业务需求文档与模型，并得到用户的认可后，则进入下一个循环。以至于生成一个版本。这样由于存在这样的版本，用户则不能将项目的延迟归于项目组。而项目组也存在一个完整的版本管理体系。