4.
目前实施项目规范的考虑
由于目前软件开发实际情况的约束，完全按照RUP实施项目管理是一个理想化思路。在实际实施中会受多方面的影响（如客户要求、小组成员素质等），这种盲目的追求标准只会做成项目的阻碍，基于这种考虑，我认为根据实际情况采用分步实现的方式，逐步建立起一支稳定的、技术分工合理的开发TEAM，才能采用RUP管理规范实现省时、合理的软件开发。
下面我根据自身对项目管理的认识，对原有项目管理中的问题进行总结，并对目前如何实现软件工程，及对本项目管理规范的实施进行了相应说明。
目前我们的软件开发多为瀑布式开发，项目管理可以说是没有。所有的管理与软件设计都是由项目经理一个人来负责，这样对项目经理的要求较高。项目开发主要依赖于个人能力，开发中又总是依靠程序员高手来支撑，最好是要有一批“快枪手”。而高手又因为多种因素不能集中在一个项目中，同时高手的流动会给项目致命的打击。以上等等只是项目管理中的一部分问题。我对项目管理中之不足归纳为以下几个方面：
项目开发人员的个人素质不同，根据素质进行角色与行为划分是项目管理中的一个非常重要的环节。
l
责任心
我在项目管理中曾遇过这样一种情况，有个项目成员技术不错，但是在开发的关键时期为个人的一点小事而不顾整个项目的进度，而其在项目中担任了比较重要的职务，在他看来，项目不如自己个人的小事（可做可不做）重要，所以造成项目进度的延误，我不得不去物色另外一个人来代替他。但后果已成。
还有一种情况，安排了某人工作，工作量在你的估算内，但是到了检查时，他对你说“我不会做”，“我不知如何做”之类的话，而同时他还在上网或做其他的事，但作为已有计划的你来说，则是项目进度被打乱的后果。
这种人当然在下一个项目不会被用，但是如何避免这种情况的发生呢？我认为应当将工作量细化到天甚至于小时，遇到这种员工则可立即开除，同时损失的工作时间是可控的。从而减轻了对项目开发的影响。
l
个人能力
程序员的领悟力各不相同。对不同的人要采用不同的方法来工作。
对个人能力高的人你可以务虚的谈工作任务，他在接受任务的同时就可以提出这样那样的问题，甚至想到你没有想到的问题，直到把问题搞清楚。这样的人你可以放心的让他去做，因为他已经完全理解了你的意图。
对个人能力一般的人，你讲什么他不能理解的很清楚，有的为了面子不懂也不说,但是在做的时候出了问题，在你指着他做的程序大骂的同时，你的项目进度在拖延。对于这种情况，你只能写出对他工作的要求，写出你的意图，明确工作目标。
对个人能力差的人你不能说只是写个要求就行的，那样的话他写的程序依然会让你忍无可忍，怎么办，把系统中技术要求较低的部分分出来，然后按1，2，3，4步骤写出来。有人说这样还不如自己写完算了，但是这种工作往往是重复量很大。如做界面等。
当然，RUP的实施方针希望是淡化个人力量，而注重流程与大家的协作，同时细化了系统的每一部分。但是RUP的实施不能教条化，在实行中还要根据项目实际情况而变化。
l
自我约束能力
自我约束能力主要是指对管理者而言的。因为项目成员工作基本是由项目管理者来监督实施的，那管理者呢，可能没有人来管理，如果管理者的自我约束能力不强，那样建立什么样的软件工程规范都无法实施。
在实施项目管理规范时，由于条件限制，不可能一下完备软件工程所需的各个机构部门，从而也可能不存在与项目组平行的流程管理机构，质量审批机构等。由于采用逐步实现的方法，所以提高约束力只能采用其他方法。
针对这种情况，可以采用各种提醒方式：电子系统如掌上电脑；人员提醒如部门技术秘书等。
用户需求的不断变化是令项目开发中最头痛的问题了。我们在做项目时传统的做法是，新需求来了，赶快叫程序员们改，在这里加一块，那里补几行代码，只要实现就行。结果是项目做完了，再看自己设计的系统已面目全非。还谈什么可重用性，可定义性，产品化，甚至下一个差不多的项目还要花费同样的时间。
RUP中强调的循环概念
就是针对于这种情况提出的，通过项目小组之间各种角色的循环，实现对用户需求变化的问题解决。如下图
这样采用迭代法开发可以实现此问题，是的，但是要有所牺牲，那就是时间。时间充足我们自然可以按照标准的RUP思路来进行。而实际上呢，又是我们牺牲不起的。现在国内大多数项目具有这样一个共同点：用户要求急。如我们做一个基金的核心业务系统，用户说开发时间为两个月。而由于基金是个新行业，无可用之部件，两个月的时间是不可能进行迭代开发的。同时我们还要在一定程度上避开需求不断变化。我建议采用的方式如下：
l
按阶段地进行循环
实现阶段性的循环，并且存在多个循环的并发。如业务需求循环在一个阶段内将生成相应的模型与业务需求文档，并得到用户的认可，然后转入系统需求循环,在系统需求转入另一个循环时,再继续业务需求循环，但此时只是记录用户需求，而不进行下一个循环。待根据最初需求制作的版本生成后，再根据新的业务需求及与用户协商结果再决定是否开发下一个版本。
l
采用快速原型法
快速原型法的作用是为了让用户在感性上了解系统的概貌，通过与用户的交流，从而固定了相应的元素（如输入参数、跳转顺序等），通过快速原型法与用户进行交流，能很好的理解用户的意图与需求，是缩短开发周期的良好途径。
l
生成一个版本
用户需求是不断变化的，而且任意性很大，如果一个项目根据用户需求的变化而变化，那么开发周期是无法估量的。一个三个月开发周期的项目做了六个月，还没有一个象样的系统出来，用户则不断的埋怨开发力度不够，管理不好等，项目组又认为是用户随意性太大，导致了这种后果。结果是双方互不满意。
根据这种情况，我认为在业务需求循环到一个阶段，生成正式的业务需求文档与模型，并得到用户的认可后，则进入下一个循环。以至于生成一个版本。这样由于存在这样的版本，用户则不能将项目的延迟归于项目组。而项目组也存在一个完整的版本管理体系。
有个朋友曾经问我在开发项目时什么时候让你感到最浪费时间，我想了想，说是“当我很忙，但项目成员却无所事事的时候”。细想原因，归根到底是工作流程的问题。为什么这样说呢，传统开发时，当项目经理与系统分析员进行业务需求和设计时，通常认为项目成员没有什么可做的，在项目过程中，做一些系统更改时，认为程序员水平不够，帮不上忙。于是乎，程序员似乎理所当然地休息一下，上上网，打打游戏。时间就这样被浪费了。
这个问题就是我们在此规范强调的重点之一：工作的并发性。
下图是实现工作并发的一种方式：
在工作中实现并发，是合理地安排项目开发的重要环节，以避免不必要的浪费，同时通过合理分配工作量的方式，减轻了传统项目中项目经理的压力。
l
淡化个人的力量，突出团队的协作
在项目开发过程中，最麻烦的就是个别‘高手’的要胁。这种‘高手’掌握了系统关键的部份，并且此时无人可替，非他不可，这时‘高手’借机要求加薪，升职。。。。。。
如何避免这种情况的出现呢？
我认为是细化工作量，不要象以前的开发中那样，说某某，你负责某个模块。而是尽量细化工作内容，基本上应细化到每工作日，如果细化到工作时则更好。同时建立相互依赖关系，实现开发上的并发，每一个程序员的工作延迟，将牵涉到几个程序员的工作，这样，其他程序员为了在工作日中完成工作，就必须相互帮助。从而实现了团队的协作。
l
做好项目总结
项目总结是非常必要的。在项目总结中要对项目或开发阶段中出现的问题进行一一归纳。其中包括技术总结，工作总结，行为总结，从而促进项目人员的成长并能在下一个阶段或下一项目中避免相应的问题。
技术总结主要是对开发中所出现的技术问题进行总结。一个程序员开发的程序在被测试员测试后，或被代码复审人员检查后，发现了问题，如废代码过多，调用错误的参数等，此时你不应立即打断程序员的工作，因为那样会打扰程序员现有工作的思路。在项目总结会上，可以把他写的代码公布给项目组人员共同阅览，让大家给他提意见，这样使之有了进一步的提高。
工作总结是指在开发过程中出现的其他问题，有些人能力差，有些人能力强，能力差的总是拖大家的后腿，这样导致众多意见，这样可以通用大家总结的方式，一来可以为项目管理人员重新安排工作量提供参考，二来也在以另一种方式对程序员进行激励。
行为总结是指对项目开发中个人行为所出现的问题进行总结。如个别人出现了消极怠工现象，那样大家来总结一下，如果是外界因素如家庭等的影响，则看项目组成员是否可以帮上忙，或者由项目管理人员进行工作安排的协调。如果是上面说的‘高手’故意摆谱，则把事情讲清楚，由项目管理人员进行相应的处理。
l
流程管理
习惯于传统开发模式的程序员可项目经理可能不愿意按照项目管理规范来做。认为这样做麻烦，要写的文档无数。在实施的过程中往往按自已的一套来做，从而造成项目的拖延。所以说，对项目中的各个流程都有相应的机制来监督，RUP中所谈到的流程管理是与开发相并行一个机构，但在目前的情况下，可能无法实现。那样就必须建立相应的机制来处理，以避免不必要的损失。
由于我们现在还处在原始的项目管理阶段，实现一步到位是非常困难的，所以采用分步方式实施：
第一步
：实现初步规范（针对项目组级）
l
实现项目阶段、角色层次的初步划分
将项目阶段划分四个大的阶段（如第一章），以里程碑的各项指标（指标根据实际情况缩减）考核项目组。
将项目组人员划分成不同角色（一个人可能是多个角色），明确分工，加强协作。（角色根据实际情况缩减，基本上是业务人员、架构设计师、系统分析员、项目经理、环境配置人员、数据库设计人员、系统集成人员、程序员、测试员、复审员、文档员、界面设计人员）
l
项目工作重心转到分析设计部分
将工作重心转移到分析设计来，分析设计分为两个方面，一方面是对系统功能与架构等系统设计，另一方面是指将系统分析细化至功能及类一级，并写出对类的要求，如参数，功能等。
l
规范工作流程
将工作流程划分为业务需求、环境配置、分析设计、项目管理、实施。严格按照项目规范进行管理。
l
更改分析设计方法
采用OO设计方式，实现CMM2可重复级。
l
实现文档模型规范化
形成各种所需文档模板，采用RATIONAL
ROSE进行UML建模。建模程度至少达到Logical
View一级。并形成相应的规范，如编码规范、建模规范。
l
建立简单的流程控制机制
主要通过技术秘书，部门经理进行流程控制。
第二步：根据项目管理规范组织一支合理的开发队伍（针对部门级）
l
统一规化部门的开发队伍
以部门为单位建立统一的开发队伍，将程序员级与测试级分离出来，并考虑采用外包方式进行代码一级实施。培训分析设计人员，建立强有力的分析力量，并细化工作分工，不再以单纯的项目组的形式来进行组织。
l
细化工作流程
细化工作流程的各个环节，减少一个人所承担的角色数量。加强相互间合作。
l
增加细化工作模型与文档模板
细化规范各部门的文档要求，增加细节文档，并提供文档模板与模型要求。
l
建立相应的产品化机制
增加产品化工作流程，由产品化工程师对相应行业系统形成产品，实现CMM3可定义级。
l
定量管理和控制软件过程和产品
收集详细的软件过程和产品质量的特征
l
建立相应的流程管理机制
由流程工程师控制软件流程
第三步：实施统一的软件工程（企业级）
建立软件工厂，达到CMM5级（优化级）
|