|
引子 风险管理虽然在CMMI/GJB5000A中占有非常重要的位置，成熟度二级的时候就有风险标识和风险跟踪，在成熟度三级 的时候，更是专门有一个关键过程域（3个目标，7个实践）对风险管理提出更加明确的甚至是定量的要求。 可是，在实际实施过程中，风险管理并没有得到足够的重视。通常的做法只是借用组织风险库的几条风险，照猫画虎，按照既有的规程跟踪记录而已。更糟的情况是，原封不动地照搬下来，敷衍了事。这样的风险管理的效果可想而知。 究其原因，很多项目经理并没有理解风险管理对于软件开发的意义。 风险之源 软件开发并不仅仅只是“写代码”，它包括项目策划、软件实现、验证和确认等一系列的活动。而每一种活动如果都能按计划100%完成，才能确保软件开发活动顺利完成。但是，谁也不能确信这些活动可以100%完成，因为在实际开发过程中存在太多太多的不确定性，而这些不确定性就会给我们想要100%完成这些活动带来风险。 所以，风险管理实际上就是控制这些不确定因素，这样才能使我们的开发活动不会和我们的预期偏离太远。 通过以上分析，我们可以得出一个结论：风险管理实际上就是软件开发活动中各种不确定因素的有效控制方法。风险管理等价于不确定因素管理。 这样识别风险 基于这样的认识，风险识别就是找出开发过程中的不确定因素。而要找出不确定因素，就要从定义好的项目过程活动出发，而且这个过程定义要细化到一定程度才行。 比如项目估计活动。通常项目估计活动包括估计准备、估计讨论和计算估计结果等活动。如果进一步细分，估计准备可以包括以下活动：
要找出估计准备的不确定因素，不妨针对估计准备的每项活动，打上一个或几个问号，如果对每个问号不能得到肯定回答，就得到了一条不确定因素或风险。比如对估计准备的第1项活动提出一个这样的问题： 软件产品的WBS分解是否完全覆盖了需求？ 如果回答不是肯定的，就得到了一条风险： 软件产品的WBS分解可能有遗漏导致软件规模估计结果错误 又比如，对估计准备的第2项活动提出一个这样的问题： 参与估计的人员是否熟悉估计规程、估计方法？ 如果回答不是肯定的，就得到了一条风险： 由于参与估计的人员不熟悉规程可能导致估计时间延长 但是，对于这样的风险，造成的后果仅仅是估计组织者现学现用，导致估计时间从1个小时变成2个小时，其对项目的影响可以忽略不计，所以没有必要将其列入风险列表进行跟踪。 通过这样的处理，我们可以识别出很多风险。而且这些风险还会在后续的过程中确认其是否被排除、被关闭，或其被降低。 风险控制与里程碑评审 风险控制还驱动了软件过程模型的发展。
也就是说，过程模型的焦点是解决开发过程中的风险，并不是以完成多少文档或代码来决定过程的进展的。 比如RUP（Rational统一过程）就致力于在早期初始阶段和细化阶段时解决项目存在的主要风险，以确保后期不会出现重大的、危害项目的风险。 风险控制的一个重要环节是里程碑评审。在CMMI/GJB5000A中，有个子实践明确指出了里程碑评审要评审的内容——里程碑评审项目的承诺、计划、状态和风险。而实际上很多组织在评审时通常只关注任务的完成情况。面对充斥着任务100%完成的评审材料，评审专家们大都提不起兴致，经常性地把里程碑评审从一个管理评审转变成技术评审。因为不知道该评审些啥。“这些项目有状态有什么好评的？”，是这些专家心里一致的声音。 可是，软件过程模型设计里程碑评审节点的一个重要目的就是确认本里程碑已经标识的风险（或不确定因素）是否已经关闭、已经排除或者已经降低。如果风险或不确定因素并没有排除或者降低，那么就不应通过里程碑评审。 如果把风险作为里程碑评审的关注点，评审的人员就要考虑前期识别的风险类别。如果有管理风险，就邀请高层管理者参加评审；如果有技术风险，就邀请技术负责人来参加评审。同样的，提交上会的评审材料，也要包含能够表明风险排除或降低的材料。这样的里程碑评审，还会觉得无关紧要，或者无聊吗？ 小结 风险就是开发过程中遇到的那些不确定因素可能给项目带来的危害。控制了风险，也就控制了这些不确定因素。整个开发过程就是一个识别风险、控制风险、排除风险，以使软件产品顺利交付的过程。 微信号：IdeaofSE |
|
|
