22 改进风险管理处方

 
如何进行风险管理（改进版）
说到底，风险管理就是执行下列步骤，并将其贯穿项目的全过程：
通过风险发现过程调查出项目面临的风险；
确认软件项目所有的核心风险都已出现在你的调查结果中；
针对每项风险，完成下列“家庭作业”：
* 为风险命名，并提供一个唯一的编号；
* 通过头脑风暴找出这项风险的转化指标 —— 风险具现的所有征兆中最早出现的那个；
* 估算风险一旦发生可能对成本和进度照成的影响；
* 估算风险具现的可能性；
* 计算风险的日程和预算暴露值；
* 判断如果风险开始转化，需要采取哪些紧急措施；
* 判断需要在风险转化之前采取哪些缓解措施才能保证应急措施不致失败；
* 将缓解措施列入到项目的总体计划；
* 将所有细节记入一个模版
指出项目的致命风险，将它们列为项目假定。执行风险移交仪式，将他们转交给上级；
假设没有任何风险具现，进行第一次日程估算。换句话说，估算的第一个步骤是要找出极小概率点 N —— 第一个让你不能有绝对把握地说“不可能在那天完成”的日期。与业界常见的做法不同，我们建议你将N点作为进度规划的输入条件，而不是输出结果。使用你的参数化估算工具（如果你有的话），并将所有参数设置为最乐观的情况，就能够得到 N 的值；
下载 RISKOLOGY ( http://www.systemsguild.com/riskology) ，并将项目参数输入主工作表。然后，输入你所能找到的所有自定义因素（来自企业对过去项目的记录数据）。经可能的覆盖模拟器中关于风险的业界数据，并将它们替换为来自你的环境的更可靠的数据。为你要跟踪的每项非核心风险创建自定义的工作表。最后，运行模拟器，使其绘出项目的风险曲线，曲线与水平轴的交点为 N；
从此时起，用风险图来描述所有的承诺，明确指出每项预计日期和预算所涉及的不确定性。客户对于风险图的概念通常知之甚少，但你不必费力向他们解释，把它解释为一个模拟器对项目进行500次模拟的结果好——这里有所有可能的结果，以及每种结果的相对可能性；
创建一个工作细分结构，用于展示完成项目所需的所有任务。估算每项任务所需的工作量。我们将以一种略显与众不同的方式使用这些估算结果：只关心任务工作量的相对权重，而不考虑他们的绝对值。这些相对权重将作为输入条件，用于计算 EVR 度量值；
在项目开始时，必须要求参与各方确定产品的净输入/输出数据流。在整个项目日程安排的前12%～15%时间里，你应该能够得到所有净输入/输出数据流的完整定义（精确到数据元素级别）。项目各方签字认可这些数据流，这应该被视为一个重要的项目里程碑。如果没有完成这个里程碑，切勿贸然进行后续的任务。请谨记：这项重要的工作 — 净数据流的签字认可 — 如果没能完成，意味着项目可能全军覆没。
在实现任何功能之前，首先进行详细的设计划分。将设计划分的结果作为输入条件，创建增量式交付计划；
设计划分完成之后，回到工作细分结构，重新估算任务的权重，并以在剩下工作中所占的百分比的形式描述每项任务；
估算项目的价值，精度应该与成本估算的精度相当；
将项目规约中包含的需求细分到元素级别，按照各需求元素的优先级顺序为它们编号。在评定优先级时，对于用户的净价值和技术风险时两个重要的因素；
创建增量式交付计划，在其中将整个产品细分为多个版本。所有需求的元素都必须被分配给各个版本，优先级越高的需求应该在越早的版本中实现。计算每个版本的 EVR，将结果记入增量式交付计划。增量式交付计划应该是项目的重要产品之一；
为整个产品创建最终的总体验收测试，然后将其分为多个 VAT（版本验收测试），每个版本都应该有一个对应的 VAT；
根据各版本的预期交付日期为它们分配 EVR。每当一个版本通过 VAT 时，在同一幅画上实际的 EVR 值；
从项目开始到结束，密切监视所有风险的具现情况或终止情况，一旦风险具现，立即执行应急计划。监控 EVR 的滑行路线及其与预期路线的吻合程度。如果实际路线与预期路线发生偏差，很可能是有风险出现了；
从项目开始到结束，持续进行风险发现过程，随时发现后续出现的风险。
风险控制表