双赢的选择
Barry Boehm的双赢螺旋过程模型融合了众多优秀的成果，它结合了
◆螺旋开发生命周期
◆度量方法（特别是COCOMO II）
◆风险管理
◆团队交流的“W理论”
按照双赢理论，项目应该预先找出所有参与者，并要求每个参与者描述所谓的“赢状态”——在他/她看来项目成功的标志。
一队彼此冲突或者彼此钳制的“赢状态”就代表一项风险。
更多的双赢开发模型信息可以参考http://sunset.usc.edu/research/WINWIN/winwinspiral.html

第十五章 风险管理动力学

项目通常是在进行到中间时开始偏离航线，那时才是最需要风险管理的时候。问题的肇因总是在那之前出现，但真正发现问题一定实在项目中间，这个阶段称为项目的“报应期”。

第十六章 增量式开发与风险缓解

风险缓解进行投入/产出比分析：风险缓解本身的成本是投入，可能发生的风险因为风险缓解措施的存在而减轻损失的加权估算值是产出。

增量交付计划是由另外三件项目产品共同构成的：
设计蓝图：由于展示需要实现的最低层次的模块和类，以及其间关系的图表。
工作细分结构（WBS）：描述需要完成的任务及其彼此依赖关系的网络。
版本验收测试计划：描述各个版本的产品可以接受哪些测试。

需要为增量交付计划和与其相关的项目产品加上两条限制。首先，对于横跨多个版本的任务，增量方法允许他们之间有一定的时间重叠。第二，设计蓝图必须展现设计划分的全貌，必须详细到最低的级别。

EVR（earned value running）挣值运行。挣值是用于度量“项目某一特定子集的预期成本”的标准。

第十七章 风险化解的中级策略

即便你做不到，提前开始仍然重要

勇敢的管理和怯懦的管理。毫不犹豫地开始一个项目是勇敢的象征；与此相反，犹豫不决则是怯懦的象征。项目开始得太晚则意味这最高层的管理者缺乏眼光和勇气。

第十八章 价值量化

成本和收益应该在同一精度上指定。
不认真做收益预测和实际收益评估的企业还常常会使用这样一条理由：收益极少，甚至根本不存在。我们有一条通用的经验法则：如果收益根本没有被量化，就当它不存在。

收益计算的五步骤
◆在开发者说明预期成本和日程安排的同时，客户说明预期收益，两者应有相同的精度。
◆在开发者指明成本和日程计算不确定性的同时，客户以相同的方式指明收益预测中的不确定性。
◆客户估算系统各组成部分的相对价值，为版本选择、敏感性分析和增量成本收益提供基础。
◆管理者比较成本和收益，并考虑个子的不确定性，对项目做出综合评估。
◆项目完成后，管理者核算实际收益，并将核算结果输入事后分析过程。

第十九章 价值，另一个不确定性

对于主要目标是提高市场竞争力（而非降低工作成本）的系统来说，收益的确有相当大的不确定性。

如果你听到自己在说“我不知道”，就应该马上切换到不确定性模式，开始画不确定性图。

系统的构建者和客户应该承担对等的责任：构建者保证交付系统，客户保证系统能提供足够的价值。

第二十章 敏感性分析

有必要由系统使用者和客户承担价值估算和十驾价值度量的责任，但是你不能强迫客户承担这份责任，所以必须软硬兼施，威逼利诱。

在项目的尺度方面，系统项目表现出违反经济学的特征：如果将系统的尺度扩大一倍，需要增加的工作量将超过一倍。既然加大产品尺度意味着需要增加更多的成本，那么缩小产品尺度就能够带来更大程度的节省。

目前，开发者还很少意识到“开发更少的软件”理应成为他们的口头禅。

第二十一章 价值对风险的补偿

对于一个给定的项目，我们愿意承担多大程度的风险？答案便是项目所能提供的潜在价值。

死亡之旅项目，人们总是会强调项目的重要性：这项工作极其重要，它需要员工付出最大的努力。但是这句话难以自圆其说：既然这个项目是如此重要，为什么公司不能投入更多的时间和金钱来好好完成它呢？

死亡之旅的共同特征：
一、预期价值偏低。项目的价值太低，以致于普通的方法毫无疑问将导致收不抵支。
二、项目成员之所以甘愿舍弃私人生活，是因为他们相信这样做有利于公司。
三、它们几乎无一例外地以惨败告终。

第二十二章 改进风险管理处方

风险管理就是执行下列步骤，并将其贯穿项目的全过程。
1。通过风险发现过程调查出项目面临的风险。
2。确认软件项目所有的核心风险都已出现在你的调查结果中。
3。针对没想风险，完成下列“家庭作业”
为风险命名，并提供一个唯一的编号；
通过头脑风暴找出这项风险的转换指标——风险具现的所有征兆中最早出现的那个；
估算风险一旦发生可能对成本和进度造成的影响；
估算风险具现的可能性；
计算风险的日程和预算暴露值；
判断如果风险开始转化，需要采取哪些应急措施；
判断需要在风险转化之前采取哪些缓解措施才能保证应急措施不致失效。
将缓解措施列入项目的总体计划；
将所有细节记入记入一个模板；
4。指出项目的致命风险，将它们列为项目假定。执行风险移交仪式，将它们转交给上级；
5。假设没有任何风险具现，进行第一次日程估算。换句话说，估算的第一个步骤是要找出极小概率点N。
6。将项目参数输入到RISKOLOGY，然后，输入你所能找到的所有自定义因素。尽可能地覆盖模拟器中关于核心风险的业界数据，将它们替换为来自你的环境的更可靠的数据。
7。从此时起，用风险图来描述所有的承诺，明确指出每项预计日期和预算所涉及的不确定性。
8。创建一个工作细分结构（WBS），由于展示完成项目所需的所有任务。估算每项任务所需的工作量。只关心任务工作量的相对权重，而不考虑它们的绝对值。这些相对权重将作为输入条件，用于计算EVR度量值。
9。在项目开始时，必须要求参与各方确定产品的净输入/输出数据流。在整个项目日程安排的前12％～15％时间里，你应该能够得到所有净输入/输出数据流的完整定义。项目各方签字认可这些净数据流，这应该被视为一个重要的项目里程碑。
10。在实现任何功能之前，首先进行详尽的设计划分。将设计划分的结果作为输入条件，创建增量式交付计划。
11。设计划分完成之后，回到工作细分结构，重新估算任务的权重，并以在剩下工作重所占的百分比的形式描述每项任务。
12。估算项目的价值，精度应该于成本估算的精度相当。
13。将项目规约中包含的需求系分到元素级别，按照各需求元素的优先级顺序为它们编号。在评定优先级时，对于用户的净价值和技术风险时两个重要的因素。
14。创建增量交付计划，在其中将整个产品系分为多个版本。所有需求元素都必须被分配给某个版本，优先级越高的需求应该在越早的版本中实现。计算每个版本的EVR，将结果记入增量式交付计划。增量式交付计划应该时项目的重要产品之一。
15。为整个产品创建最终的总体验收测试，然后将其分为多个VAT，每个版本都应该有一个对应的VAT。
16。根据各版本的预期交付日期为它们分配EVR。每当一个版本通过VAT时，在同一幅图中画上实际的EVR值。
17。从项目开始到结束，密切监控所有风险的具现情况或终止情况，一旦风险具现，立即执行应急计划。监控EVR的滑行路线及其与预期路线的吻合程度。如果实际路线与预期发生偏差，很可能是有风险出现了。
18。从项目开始到结束，持续进行风险发现过程，随时发现后续出现的风险。

第二十三章 风险管理的检验

无论是风险管理责任人，或者比这更高的地位的人，必须有一种客观的途径来了解风险管理是否真的得以贯彻。

如果风险管理得到了贯彻，并且成为企业文化的一部分，你的项目应该能够通过下列全部或者大部分检验：
1。有一份风险清单。
2。有一个持续进行的担风险发现过程。
3。不确定性图随处可见。
4。项目既有目标值又有估算值。
5。每项风险都有明确的转化指标，并且有不间断的转化监控机制随时留意发现的具现情况。
6。每项风险都有相应的应急计划和缓解计划。
7。每项风险的暴露值都得到了计算。
8。项目的价值有量化估算，并承诺在项目结束之后度量实际获得的价值。
9。项目计划中至少包含一定程度的增量计划。
如果你的企业能够通过上书检验中的6项以上，你考究可以相信：风险管理已经成为了项目的一部分。

[1]   [2]