该帖子同步发自：(飞眉的博客  访问该博客)

　　风险管理包括风险评估、舒缓风险影响以及监控风险。很多敏捷用家相信敏捷开发项目风险管理过程跟传统项目差不多，虽然这过程在敏捷的内容中较为轻盈，但是在找寻、过滤、优先化以及制造解决方案上的步骤跟传统项目中很接近。

　　Mike Cottmeyer提出以敏捷开发去识别和舒缓风险影响更为有效，他指出：

　　敏捷开发方式之所以能有效管理风险因为风险管理过程建立在我们执行项目的结构上，这隐含的意思就是风险在项目中无处不在，风险清单不能包括所有风险，也不能透过团队会议和定期的风险评估来减轻风险，风险处理必须是不能抽离的思想，我们减轻风险的策略不是处于项目以外，而是影响着如何规划和安排工作的本质。

　　他把风险分成三类：

　　业务风险 – 涉及项目付运能否带来它所预期的价值

　　技术风险 – 涉及技术方案在若干时间及资金下的可行性

　　后勤风险 – 涉及人与其他基建之间的假设

　　根据Mike所说，敏捷开发的本质就是要求频密的付运、定时的检察和调整，这本身已经是风险管理。

　　但是也有人认为敏捷开发不是固有地处理风险。

　　Jurgen Appelo认为敏捷项目经常缺乏风险的关注。

　　他认为，

　　Prince2、PMBOK、CMMI都有包含风险管理的部份，但敏捷方法的书本上就很少明确地看到风险管理的内容，对此我感到莫名其妙。

　　他同時指出，项目经理经常埋头在项目里，而忽略了整体宏观形势，这导致严重缺乏对风险管理的关注。

　　另外，James Shore认为有效的风险管理能帮助团队作出更实在的承诺，他建议使用风险倍数(risk multiplier)和Burn-up图来管理项目有关的风险。

　　风险倍数包括常见的风险，例如人事变动、要求改变、工作上的障碍之类，这些风险倍数让你更准确地于设定日期和估计需要多少故事点数(story potints)。

　　James建议在团队使用较为精确的开发过程(相对于风险较高的开发过程，可参考James网站上这例子)，而且速度(velocity)固定、每个故事都在迭代完结时做到"Done Done"(不仅完成客户需要的功能，而且没留下支持团队的工作，原文出至于James的网站，亦可参考"The Power of Done"一文)的情况下使用以下的风险倍数。

　　风险倍数

　　(这些倍数来至DeMarco和Tim Lister的RISKOLOGY模拟器(详文可参考「与熊共舞」一书)以及Todd Little的分析数据)

　　这风险倍数使用方式如下：

　　(假设团队的速度为14，十个迭代后发布的话，那么当前可运用的故事点数有140点)

　　从以上例子中：

　　让你可以跟项目有关人士和管理人员说：「我们几乎肯定会在发布前完成当中的78点，所以我们先承诺完成功能A、B和C，我们有一半机会能完成总共100点，所以我们安排功能X、Y和Z作为伸延目标，完成好A、B和C之后再去完成他们的。」

　　所以风险管理在敏捷项目中就如传统项目一样，都是核心部份，重点在于适当的重视、有效地处理而基于这里作出承诺。