简介 “有备无患。”－ Hamlet V:ii:215
项目就像生活一样，是不确定的。我们不是为了识别风险而识别风险，而是尽可能要预见和降低风险，或在我们的降低策略不足时响应风险。
风险推动了迭代计划；迭代是围绕着处理特定风险而计划的，尝试限制风险或减少风险。定期复审风险列表可评估风险降低策略的效用，这反过来又推动了项目计划的修订及随后迭代计划的修订。
管理风险的关键不是等到风险成为事实（并成为问题或故障）后才决定如何处理。就像在洲际飞行中失之毫厘则谬以千里一样，较早地管理风险几乎总是比事后清理代价更低，麻烦更小。
风险管理策略 有三种主要策略 [BOE91]：
避开风险。重新组织项目，使其不会受该风险的影响。 转移风险。重新组织项目，使其他人或事承担该风险（客户、供应商、银行、另一元素等）。一种特定的避开风险策略。 接受风险。决定忍受风险，作为一种偶然情况。监视风险症状并确定一个出现风险时的应急计划。 如果决定接受该风险，您仍可能希望降低该风险，即采取某种直接措施来减少其影响。
风险的类型 区分直接风险和间接风险是很重要的。简而言之，直接风险是我们能在某种程度上控制的风险；间接风险是我们无法控制的风险。
尽管不应该对间接风险一无所知，但它们在实践意义上是无关紧要的：既然无法更改它们，对它们有所顾虑也无济于事。尽管可能明天就是世界末日， 但也可能不是世界末日，如果不是的话，我们最好继续做好手上的事情！
有时，间接风险可能实际上是伪装起来的直接风险。例如，我们可能依靠某个外部供应商提供一个组件或一组组件。这似乎是间接风险，但通过针对这些组件的应急计划，我们可以控制该风险：我们可以选择替代供应商，或我们可以选择自行开发功能。在许多情况下，我们比想像中的更有控制权！
对于间接风险，您要么必须找出如何对这些风险获得某种程度的控制的办法，要么只是记下它们并继续。对您无法改变的东西牵肠挂肚是没什么意义的。
资源风险 组织对此项目是否有足够的投入（包括管理层、测试人员、QA 和其他的外部相关各方）？ 这是否是该组织曾尝试过的最大项目？ 是否有明确定义的软件工程流程？是否有明确定义的需求捕获和管理？ 拨款拨款是否到位、可以完成项目？ 是否分配了用于培训和指导的拨款？ 是否有预算限制，这样系统就必须按固定的成本交付、否则取消？ 成本估计是否精确？ 人员是否有足够的人员？ 他们是否有适当的技能和经验？ 他们以前是否合作过？ 他们是否相信该项目可以取得成功？ 是否有用户代表进行复审？ 是否有领域专家？ 时间时间表是否现实？ 是否可按时间表管理功能的范围？ 交付日期的紧急程度如何？ 是否有时间“正确行事”？ 业务风险 如果竞争对手先进入市场，怎么办？ 如果项目拨款受到威胁，怎么办（看待这个问题的另一方式是询问“怎样确保拨款充足”）？ 系统的计划价值是否大于计划成本？（务必考虑到金钱的现值和投资的成本）。 如果无法与主要供应商签订合同，怎么办？ 技术风险 范围风险是否可以度量成功？ 是否有关于如何度量成功的一致意见？ 需求是否相当稳定并得到清楚的理解？ 项目范围是固定的还是一直在扩展？ 项目开发时间范围是否短暂而不灵活？ 工艺风险该技术是否已得到证明？ 重用目标是否合理？ 工件必须在使用一次后才能重用。 一个组件能需要发行好几个发行版，然后其稳定性才足以重用而不需要重大更改。 需求中的事务量是否合理？ 事务率估计值是否可信？是否过于乐观？ 数据量是否合理？它们是否可存储在当前可用的大型机中，或者，如果需求让您相信工作站或部门系统将是设计的一部分，数据是否可在那里合理存储？ 是否有不常见的或挑战性的技术需求，要求项目团队处理他们不熟悉的问题？ 成功取决于新的或未经尝试的产品、服务或技术、新的或未经证明的硬件、软件还是工艺？ 是否有对其它系统（包括企业外的系统）接口的外部依赖性？必需的接口是否存在还是必须创建它们？ 是否有极不灵活的可用性和安全性需求（例如，“系统必须永不失败”）？ 系统的用户是否对正在开发的系统的类型没有经验？ 是否由于应用程序的规模或复杂性或者技术的新颖性而增加了风险？ 是否要求本地语言支持？ 是否可能设计、实施和运行此系统？有些系统只是由于过于庞大或复杂而无法正常工作。 外部依赖性风险项目是否依赖于其它（并行的）开发项目？ 成功是否依赖于成品产品或外部开发的组件？ 成功是否依赖于开发工具（设计工具、编译器等）、实施技术（操作系统、数据库、流程间沟通机制等）的成功集成。您是否有在没有这些技术的情况下交付项目的备份计划？ 时间表风险 经验表明，85% 的风险对时间表有着直接或间接影响，因此肯定对成本有影响。可能其中的 5% 仅有成本影响。其余部分对成本或时间表没有任何直接影响，但对质量（举例）有直接影响。
如果截止期限是大敌，则在平稳接近该期限的过程中进行递增的交付。避免为了努力符合时间表而进行一次性大量交付。
某些项目具有真正的“突然死亡”截止期限。例如，要在选举之夜“现场”分析选举结果的软件，如果在选举后的一周才开发出来，那就没什么价值了。或者您的软件可能被竞争对手所超越：它们将一个更好的产品投放市场，而您还处在构建过程中。突然之间，您出局了 － 并且您对这种情况无能为力。但总的来说，很少有项目具有这样紧迫的截止期限。延迟通常影响到成本。
总的来说，您承诺的时间表应等于您的最佳估计情况加上一些合理的偶然情况。
承诺 = 估计 + 偶然
其他人曾建议将时间表期望设置为相当于您的退路策略，即，基于您的应急计划设置时间表期望，但这有点过于悲观了，因为并不是所有风险都将成为事实。
时间表风险集中在一些估计和成本计算工具中。例如，在 COCOMO 模型中，有许多成本驱动因素，例如：
复杂性（cplx） 实时约束（time） 存储约束（stor） 经验（Vexp） 好工具的可用性（tool） 时间表压力（sced） 是实际的风险因素。
免责声明：本文为网络用户发布，其观点仅代表作者个人观点，与本站无关，本站仅提供信息存储服务。文中陈述内容未经本站证实，其真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
