活动:
|
目的
|
|
角色: 项目经理 | |
频率:按照要求,通常至少每个迭代一次。 | |
步骤 | |
输入工件:
|
结果工件: |
工具向导: |
工作流程明细: |
目的 | 为项目列一份“可能出故障的部分”的清单。 |
将项目团队集合在一起(团队在此时应还很小;如果项目团队的人数超过五到七人,则将风险评估流程限制在仅活动领导参加)。
当我们识别风险时,我们考虑“可能出故障的部分”。当然,如果将 范围放得最宽,那么任何部分都可能出故障。然而,目的不是要对项目产生悲观的观点,我们希望识别成功的潜在障碍,以便可以减少或消除这些障碍。更多信息请参阅指南:风险列表。
更具体地,我们是在寻找一些可能发生的事件,这些事件将降低我们能够按时地、在预算以内交付具有正确的功能和必需的质量等级的项目的可能性。
使用头脑风暴技术,要求每名成员识别一种项目风险。允许解释性问题,但不应由组来评估或评论风险。要求参与讨论的成员轮流提出风险,直到无法再识别更多风险。
要求所有各方参加此流程,无需过多担心形式或重复,您稍后可以对该列表进行清理。使用同类的人员组(客户、用户、技术人员等等)。这可以简化收集风险的流程;个人在他们的同级(在专业和等级方面)面前所受到的约束要比在一大群各种人员混杂的环境中受到的约束小。
让参与者明确,提出风险并不以任何方式等同于自愿解决该风险。如果人们有这样的感觉,即提出风险将导致会对解决风险负责,那么将无人识别任何风险(或者他们提出的风险将是不重要的风险)。
为继续进行,请尝试以一般风险列表开始,例如软件风险的评估和控制(作者 Capers Jones,[JON94])或软件工程协会建立的基于分类学的风险识别([CAR93])。传播风险列表:了解已经识别的风险常常能帮助人们识别更多的风险。
您可以引发如上所定的输入。但是通常,根据现有列表的示例,团队成员将识别新的风险,并在定期的项目状态评估中捕获新的风险。请参阅活动:评估迭代。
目的 | 对类似的风险进行组合(以减小风险列表的大小)。 按照风险对项目的影响对风险划分等级。 |
不再发现更多风险之后,请将风险列表作为一个整体查看,以查明是否存在任何自然分组(出现相同的风险),并在可能的情况下对风险进行组合以消除重复。有时,识别的风险将是一些更基本的风险的症状;在这种情况下,请相关的风险一起归到此更基本的风险下。
定量的风险管理技术建议:根据风险对项目所代表的总体风险隐患,划分风险的优先级。要确定每项风险的隐患,小组应估计以下信息:
风险的影响 | 在风险发生的情况下,进度安排、工作量或成本与计划的偏差 |
---|---|
发生的可能性 | 风险实际发生的可能性(通常表示为百分比) |
风险隐患 | 通过将“风险的影响”乘以“发生的可能性”计算得出 |
作为一个组,每项风险的隐患应根据组中多数人的意见得出。应进一步讨论观点的显著差别,以查明每个人解释风险的方式是否相同。通常此信息作为列包含在表风险列表中。
人的天性是担忧影响最大的风险,但是如果这些风险发生的可能性极小,它们的重要性其实不如那些适度的、但又常常被忽略的风险。通过同时考虑风险的大小和发生的可能性,此方法可帮助项目经理将风险管理工作的重点放在对项目交付影响最显著的区域。
一旦已确定每项风险的隐患,您就可以按隐患递减的顺序对风险进行排序,从而创建自己的“前 10 位”风险列表。
因为可能性和成本的估算代价高昂,且其自身就有风险,所以通常只需要测量前 10 到 20 位风险的影响。较小的项目可以考虑较少的风险,而较大的项目代表较大的“风险目标”,因此相关风险也很多。
除了按隐患递减的顺序对风险划分等级以外,您可能还会发现根据风险对项目的影响大小(风险大小),将风险分组或群集成类别很有用。在大多数情况下,五个类别即已足够:
记录风险,并在项目团队成员中传播它们。
目的 | 重新组织项目以消除风险 |
尽管不是始终都有可能,但有时您的确可以完全避开风险。风险常常是由不佳的系统范围造成;如果您可以减小系统范围(通过消除非根本的需求),那么风险列表的整个部分中就会删除许多需求,从而风险列表显著减小。没有足够的资源(包括时间)来完成工作并非是这些风险中最不重要的一个。
在其它情况下,可以获取技术以减少构造特定功能的风险,这是一种风险规避方式,其中一组风险(构造技术的风险)被替换成另一种风险(依赖于某人控制范围以外的力量的风险)。
最终,风险可以转移给其它组织。
目的 | 制订计划以缓解风险,也就是减小风险的影响。 |
对于直接的风险,也就是项目在某种程度上可以控制的风险,确定将采取什么操作以减小风险的可能性,或者减小其对项目的影响(缓解策略)。通常,风险本身源自缺少信息;缓解策略本身常常是“调查主题进行得越深入,不确定性就越小”。
存在一些风险,可以对这些风险执行某种操作,以使它们具体化或消除它们。在迭代开发流程中,将这样的操作分配给早期迭代,以尽可能早地缓解风险。尽可能早地面对风险。如果风险的形式是“X 可能不工作?”,则计划尽可能早地尝试 X。
示例:
这些操作的结果应是减小某些风险发生的可能性,可能几乎减小到零。在已确认了风险的情况下,使用一份意外计划对风险做出响应(请参阅确定意外策略)。
目的 | 制订备用计划 |
对于每项风险,不管您是否有积极地缓解它的计划,您都必须确定当风险具体化(也就是,如果风险真的成为问题,即保险行话里的“损失事件”)时,要采取哪些操作。这通常称为“计划 B”或意外计划。当风险规避和风险转移失败,并且风险缓解也不是那么成功时,需要意外计划,现在必须直面风险了。对于间接风险经常发生这种情况,也就是,项目无法控制该风险,或者缓解策略的成本过高而无法实施。
意外计划应考虑:
风险 |
指示器 |
操作 |
---|---|---|
风险是什么? | 您如何知道风险已成为现实?如何识别“损失事件”? | 应采取什么措施来解决“损失事件”(您如何能停止“流血”?) |
一些风险可以通过使用项目度量值、查看趋势和阈值来进行监视;例如:
一些风险可以根据项目需求和测试结果进行监视;例如:
一些风险与特定事件相关联;例如:
还有许多其它的“更软性的”指示器,它们都不能全面诊断问题。例如,始终存在士气下降的风险(实际上,在项目中的一些特定点,这几乎是可预测的)。有许多指示器:抱怨、“充满怨恨的幽默”、错过的截止期限、低劣的质量等等。所有这些“度量”都不是确切的指示器;就特定的可交付工件开发失败开一些玩笑可以是缓解压力的健康方式,但是,如果此情况继续下去,则可能指示团队越来越感到危机临近。
不经过判断来感知所有指示器。很容易将“坏消息”的传播者列为态度不好的人;在玩世不恭后面常常存在不少实情。“坏消息的传播者”常常担当“项目的谴责对象”。大多数人希望项目成功,当外力将项目带到其它方向时,他们会有挫折感。
对于简单情况,意外计划枚举备用解决方案。 影响通常是由于放弃当前解决方案并实施新的解决方案而引起的成本和延迟。
对于其它情况,“更加软性”的风险常常不是当损失发生时采取的一个操作,而是几个操作。例如,当士气下降时,最好承认该情况并聚集一组人员讨论大多数人对项目的态度。聆听问题,识别问题,通常还让人员发泄。不过,在经过适当的发泄之后,则转向解决问题的原因。使用风险列表作为聚焦讨论的方法。通过重新划分风险优先级,然后重新制订迭代计划以系统地解决排名靠前的风险,可将问题转换成具体操作计划。积极的行动强过积极(但空洞)的言语。
抛开当时的情绪不谈,发生损失也有好的一面:它迫使人们采取行动。人们常常容易通过忽略风险而推迟它们,表面的宁静使人陷于满足之中。当损失事件发生时,必须采取操作。此时的风险不再是风险,对于其发生不再有任何不确定性了。
然而损失发生也是未能规避或缓解风险的结果。 它会迫使人们重新检查风险列表,以确定项目团队是否有一些系统盲点。虽然坦诚的自我评估很难,但它可以防止以后出现其它问题。
目的 | 确保风险列表在整个项目期间保持最新。 |
风险评估实际上是持续的过程,而不是只在项目期间的特定时间间隔发生。您至少应该:
目的 | 确保风险列表在整个项目期间保持最新。 |
在迭代结束时,根据风险列表重新将注意力放在迭代目标上。尤其是:
如果您在先启和精化阶段发现风险列表增长,请勿太在意。项目成员工作时,他们会认识到某些他们以前认为微不足道的地方实际也包含着风险。在您开始进行集成时,可能会发现一些隐藏的困难。但是,在项目进行到精化阶段结束时,以及在构造阶段期间,风险应稳步减少。否则,就说明您可能没有适当地处理风险,或者您的系统过于复杂,或者不可能以系统的和可预测的形式进行构造。更多信息请参阅指南:风险列表。
Rational Unified Process
|