[与熊共舞]_3_风险管理处方

Posted 2022-12-14 小砖头1994

摘抄自：与熊共舞-软件项目风险管理（Tom DeMarco、Timothy Lister著，熊节、马姗姗 译）

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

图一：风险模板