软件项目管理Follow me之项目整体管理
第1章 制定项目计划
项目管理计划的内容根据项目的复杂度不同而有所不同,项目管理计划包括了很多附属计划,例如:进度计划、产品集成计划、配置管理计划、度量计划、风险管理计划、采购计划、过程改进计划、质量保证计划、费用管理计划等等,甚至里程碑清单、配置项列表、资源日历等也都属于项目管理计划的范畴。因此项目管理计划可以由一个或多个分计划,以及其他事宜组成,其详细程度只要满足项目的具体需要就可以。
制定项目管理计划的过程如下表所示:
依据----------------------à工具--------------------à成果 | ||
项目初步范围说明书 | 项目管理方法论 | 项目管理计划 |
项目管理各个过程 | 项目信息管理系统 | |
事业环境因素 | 专家判断 | |
组织过程资产 |
|
*本过程与之前章节相同的部分就不再重复。
依据Ø
之前已经讲过项目管理计划可以由多个从属计划组成,每个从属计划可能都对应一个管理过程。例如在PMP中可以就对应“范围、时间、成本、质量、人力资源、沟通、风险、采购”这8个管理过程;以CMMI L3为例就对应了18个PA。
因此在制定项目管理计划时项目管理的各个过程就理所应当的作为其制定计划的依据。
工具Ø
在制定项目管理计划的方法论中确定了协助项目管理团队制定和控制项目计划变更的过程。
配置管理系统包含了变更管理系统,它本身也作为项目管理信息系统的一个部分,比较典型的就是微软的TFS,TFS包含了代码版本管理的工具和工作任务的分配等功能,另外它还与MS Project等Office工具进行了集成。
软件配置管理的详细概念可以参考我之前发表的《CMMI之配置管理》。
第2章 指导与管理项目执行
在本过程中要求项目经理和项目团队依据项目管理计划,采取各种行动完成项目范围说明书中定义的工作。
指导与管理项目执行的过程如下表所示:
依据----------------------à工具--------------------à成果 | ||
项目管理计划 | 项目管理方法论 | 可交付成果 |
批准的纠正措施 | 项目信息管理系统 | 请求变更 |
批准的预防措施 |
| 实施的变更请求 |
批准的变更请求 |
| 实施的纠正措施 |
批准的缺陷补救措施 |
| 实施的预防措施 |
确认缺陷的补救 |
| 实施的缺陷补救措施 |
行政收尾的流程 |
| 工作绩效信息 |
*本过程与之前章节相同的部分就不再重复。
依据Ø
首先从指导与管理项目执行的定义来看,项目管理计划是其依据的根本。
其次大家回想一下在自己的项目中是否都开展了以下工作?
1、 软件项目的变更是最常见的,当某个变更被批准后项目组就要去执行。
2、 不管是PMP还是CMMI都专门对风险的管理过程进行了定义,风险的三要素就是“风险的概率”、“风险的严重程度”和“风险的影响”,在项目实施的过程中项目经理经常都会开展风险的预防措施以降低风险发生的概率。
3、 “同行评审”在测试理论范畴内也称作“静态测试”,在CMMI的VER中专门定义了如何进行“同行评审”,在VAL中也定义了哪些地方要开展“同行评审”活动。因此在“同行评审”和测试过程中发现的各种缺陷都要被跟踪并最终得到解决。
4、 在“同行评审”和测试过程中发现的各种缺陷得以解决后,项目组都要对其进行再次的核对。
5、 在项目进行过程中假如QA人员发现某些环节没有按照规范开展相关活动,那么项目组就要开展相应的纠正措施。
以上工作都要经过相关人员确认并批准后方可实施。
最后行政收尾和验收工作也应该属于项目实施的一个部分,因此也要作为“指导与管理项目执行”过程依据的一部分。这里的收尾特指行政收尾的过程,软件项目的生命周期都分为不同的阶段,每个阶段的里程碑评审的过程其实就是在做行政收尾的部分工作。因为里程碑评审也称为阶段末评审,具体要开展哪些评审活动是在CMMI的VAL中定义的。与客户一起进行的验收工作只是行政收尾的一个部分,例如设计完成后,开发人员就相当于设计人员的客户,因此设计完成后的评审也就相当于设计人员与开发人员进行验收交接的过程。
工具Ø
指导与管理项目执行的方法论确定了帮助项目团队执行项目计划的过程。