项目计划内容总结.doc
项目计划内容总结 项目目标 :包含进度 ,成本 ,质量三个方面的目标 .其中成本主要是人力资源的投入 .而质量目标一般应该是产品进入维护阶段后的缺陷泄露情况 .项目进行过程需求 ,设计和开发各阶段相关工件需要达到的质量要求 .这三个要素是项目的主要目标 ,相关还可能存在其它目标 .如你需要控制项目范围的变化幅度 ,你需要在项目过程中人员技能水平提高了怎样一个水平 ,你对各过程定义的偏差限度等 .整个项目管理过程和阶段的活动都是围绕相关目标进行 ,在有限的资源情况下按时按质的完成项目 . 假设和约束 :假设和约束最大的区别就是一个是确定的 ,一个是不确定的 .假设最重要的是要出一个依据 ,这个依据对项目计划过程和项目目标的实现造成影响 ,但根据项目现在已知因素又无法确定这个依据是否是一定成立的 .而约束则是这个依据一定是成立的 ,项目必须遵循这个依据 .所以假设的例子有项目假设在进入设计开发阶段后编码人员能够到位 ,假设项目执行过程中范围偏差不会超过 10%,假设项目估算依据的历史估算数据是真实可信的 .而约束我们考虑因素同样是从项目几个要素考虑 ,从进度 ,资源和质量等 .另外要考虑的就是技术约束 ,如项目所使用的开发 工具 ,技术架构 ,必须遵循的技术标准等 .如项目必须使用 **标准开发网页以满足不同浏览器浏览 ,项目资源约束在 **人内 ,项目必须在 **日发布版本等 . 项目验收标准 :太重要了 ,这是项目收尾的一个重要依据 ,项目收尾时候的项目验收必须通过项目验收标准进行 ,防止扯皮 .项目的的产出是产品 ,服务和成果 .对于每项都必须定义明确的验收准则和标准 .因此项目交付物必须是可以验证的 ,如果是一个不可验证的东西则不能称为项目的交付物 . 角色和职责 :这个一定要分清楚 ,职责和职务一般只有一个 ,但其可以承担多个角色的任务 .角色和职责间是一个多对 多的关系 .如评审员就是一个虚拟的角色 ,可能并没有一个专门这样的职务 .但需求 ,设计 ,开发或测试人员都可以担任评审员 . 项目自定义过程 :CMMI 三级的一个重要概念 ,项目应该是依据组织级的标准过程来定义项目自己的过程 ,组织级可以定义相关的裁剪标准 ,项目依据裁剪标准对保证过程进行裁剪得到自定义的项目过程 .由于多过程或输出控件的控制问题 ,一般 CMMI 并不推荐采用敏捷或迭代的方法论或生命周期模型 ,现在有专门的 AgileCMMI,是研究的一个重要话题 . 里程碑和基线 :里程碑就是对上阶段的工作进行总结和评审 ,确认阶段的交付 物是否达到了要求和质量标准 ,确认是否可以进入下一个阶段的工作 .里程碑的总历时为零 .在里程碑达到并评审通过后 ,可以对里程碑的所有交付物进行基线 ,基线的对象是配置项 ,基线的目的是保证工作产品的一致性 ,基线的工作产品做为下一个阶段活动和任务的自己输入和依据 . 项目的方法 ,工具 ,技术和标准 :这几个因素都是重要的项目要素 ,而对于敏捷方法论或敏捷项目管理则更强调这些要素 .项目在资源和进度等都能够满足项目需求情况下仍然失败很多时候的原因就是方法 ,工具或技术的选择上面出现问题 . 估算 :项目允许的工作量偏差或规模的偏差一般在 20-30%左右,而进度偏差一般要求更严格,因此对于估算的准确度最好能够在 80%以上,如果估算不准确将导致后续频繁的调整进度计划.项目管理或计划是一个渐近的过程,因此估算最好能够做两次,在软件需求出来后再进行一次估算,估算较为准确的设计开发工作量.由于功能点估算一直存在的估算项无法和最终的活动和任务对应起来 ,估算的数据功能的 EIF 和 ILF 无法分解到事务功能上面的问题 ,因此个人认为功能点估算更适合做项目总规模的一个估算.根据总规模 /生产率得到一个较为可信的项目周期数据.专家法和三点法估算是我们常用的估算方法, 三点法可以通过 PERT 计算出一个最可能的估算值,同时得到一个项目周期的估算范围数据. 进度计划 :再来谈下顺序问题,首先是确定清楚范围,选择项目的生命周期模型,然后进行顶层 WBS 分解,对分解后的 WBS 进行规模的估算,根据历史的生产率数据推算出相关的工作量数据.根据 WBS 确定出相关的活动和任务,对活动进行排序和建立依赖关系,确定项目的角色责任矩阵和资源分配准则并根据该准则对活动安排资源,绘制网络图确定关键资源和关键路径,排进度表并对资源进行平衡. 在对任务分配资源的时候,优先保证关键资源分配到关键任务上面,同时 当关键资源承担多个任务的时候一个普遍原则是: 设 A1,B1 是两个关键任务, A 的后续依赖任务是 A2,B1 的后续依赖任务是 B2, A1 可以比 B1 早 3 天开始,A2 到结束关键路径长为 L1, B2 到结束关键路径长为 L2. A.当两个从后续任务开始算起的关键路径长差不多时,关键资源优先开始可以提前开始的任务。即优先开始 A1 任务。 B.当 L1 比 L2 短 3 天以上时候,这个时候反而要优先开始 B1 任务,虽然这个时候开始要闲置关键资源,这点很重要。 人员计划:最主要是就是分阶段的人员投入计划.对于软件开发项目一般在需求和总体设计阶段仅 仅需要投入 20-30%的人员即可.因此人员计划最好是分阶段投入的计划.投入人员必须规定相关的技能要求,规定了技能要求后需要对项目人员进行技能评估,如果项目成员的技能达不到要求,则还需要制定相关的培训计划,并对培训效果进行跟踪,并将该项列入项目的风险跟踪和控制. 人员技能 :一般要求开发人员至少应该有 1-2 年的工作经验 ,这应该是一个基本的要求 .智商再高 ,基础理论再好没有经过一段时间的实战相关知识是不可能转化为技能的 .但过了 1-2 年这个阶段 ,工作经验和技能就是非线性的关系了 ,并不是说你工作经验长你的技能水平就一定 高 ,这跟个人和环境等诸多因素相关 .工作了 5年或 8年的可能技能水平一般 ,而工作了 2 年的可能技能就能够达到专家水平 . 风险计划:风险管理是项目管理的一个重要内容,风险管理的过程贯穿整个项目生命周期。风险管理计划中首先要确定风险管理小组的成员和各自的职责,对于 PDM 项目,风险小组负责人为项目经理 .风险小组确认后就要确定风险管理过程中需要使用的相关的工具和方法。其中包括风险识别的方法,风险分析的方法,风险监控的方法和风险应对的方法。这些方法和工具组织级都有明确的定义和指导原则,对于存在多种方法时要根据项目实际情况选 择。对于项目的风险来源和分类,组织级都有明确的标准和定义,项目一般都可以直接采用,但需要注意的是有可能需要项目实际情况对其进行裁剪。如项目本身不可能存在采购方面的风险时候,就需要将其裁剪到,这样在后续的风险识别和分析中都不用再过多考虑。 项目计划中的风险应对策略不是针对某个特定风险的,所以这里的应对策略更多是通用的应对策略:如开发原型,技能评估和培训,数据模拟等。当遇到实际的风险时候,如何去应对还要根据风险的实际情况进行分析。 项目计划阶段就应该分析出项目在当前状况下的所有风险,并对风险进行优先级排序,当确 认了是项目的关键风险后,需要制定这些风险的减轻计划和应对措施,这些内容都需要体现到进度计划中,进度计划必须包含这些内容才是一份完整的进度计划。 在当我们积累了足够多的历史数据后可以对风险进行组合分析和量化分析,对于风险量化分析可以采用决策树和蒙特卡洛模拟等方法进行。具体的方法可以参考以下文档 质量计划 :项目计划中要做的质量计划和 QA 要出的质量保证计划完全是不同的. QA 的质量保证计划关注点在过程和工件的一些审核上面,保证项目遵循计划和过程执行.项目计划中的质量计划更多倾向去产品的质量和要达到产品质量需要采取的 控制措施.质量目标中来源与用户对质量的要求,来源于项目至少质量改进需求,来源于历史项目的相关经验,因此首先应该制定出相关的质量目标,然后根据质量目标去估计项目的缺陷趋势和各阶段缺陷数,为了达到质量目标所需要投入的评审,测试和 Review 等相关的工作量.对评审和测试的覆盖率的要求,有这些数据后就可以估算出项目的质量成本 COQ,COPQ 和 COGQ.