风险管理是传统项目管理中的重要部分，也是项目管理协会(PMI)知识结构体中的知识领域。在我的很多课程中，参加培训的人会问在Scrum和敏捷项目中如何定位风险管理。一部分人顾虑Scrum或者敏捷项目中会完全忽略项目管理。让我们来看看为什么会这么理解。
首先，大量明确的风险管理在敏捷项目中变得不是那么必要了。短期的迭代，一门心思完成可以工作的软件，强调自动化测试，经常交付给客户，可以帮助大多数项目避免可能面临的最大风险－最终无法交付产品。所以很多敏捷项目放弃明确的风险管理也就不足为奇。对于那些明确的风险管理所带来的开销大于收益的项目来说，不如放弃明确的风险管理。
因此对于周期短风险低的项目，可以没有正规的风险管理，周期长风险高的项目则比较适合明确的风险管理。来看看我们怎么做，我先解释一个技巧：风险燃尽图，这是2004年在敏捷时报(The Agile Times)由John Brothers提出来的。
以前我们创建风险燃尽图的时候，我们首先需要一些类似于典型风险统计的东西，也就是一个列表，包含项目的主要风险、项目可能发生的概率、风险发生后损失的大小。请看下表，我简化到只留下了必要的几列。
|
风险 |
发生概率 |
损失规模（以天为单位） |
已经暴露的风险（以天为单位） |
| 备份和恢复可能需要引入第三方的产品 | 20% | 15 |
3 |
| 缺少相关数据会影响合作伙伴A对产品的验证 | 35% | 20 |
7 |
| 合作伙伴没有足够的时间对分析报表的格式提供反馈，意味着在验证期间才会发现报表不能用 | 10% | 5 |
0.5 |
| 合作伙伴A的员工要到很晚才能去验证新的功能，造成我们无法发布额外的版本解决他们可能没有发现的问题 | 20% | 5 |
1 |
| QA缺少时间验证所有操作系统和所有浏览器 | 40% | 5 |
2 |
| 合作伙伴A可能需要比我们能提供的更多的用户文档 | 25% | 20 |
4 |
|
已经暴露的风险总计 |
18.5 |
||
这个简化的风险统计表统计表描述了每个风险，提供了可能发生风险的估计， 一旦风险发生对日程表造成的影响，预期的风险暴露（损失与概率的乘积）。我建议在第一个Sprint计划会议中就创建风险统计表，在以后的计划会议里一旦发现新的风险，或者已知风险的发生概率或者损失大小发生改变的时候，就及时更新风险列表。
接下来可以通过标出统计表中所有风险暴露的累计值来创建风险燃尽图。我的建议是如果出现太多的风险，只累计前十大风险就够了。即使前十大风险改变了项目的进程也要继续绘制风险燃尽图。一个简单的风险燃尽图如下：
而一般的发布燃尽图，我们可以看到随着项目进展，风险呈线性下降，如下面的风险燃尽图的红线所示：
原文作者： Mike Cohn
原文链接：
http://blog.mountaingoatsoftware.com/managing-risk-on-agile-projects-with-the-risk-burndown-chart
关于译者：
何幸杰( Mark He) SAP Labes 工程师，Scrum Overview Trainer。在SAP之前，他曾在EMC,Flextao担任过项目经理和工程师。他2006年开始陆续接触敏捷开发，从懵懵懂懂到现在成为敏捷的簇拥。有一定的项目管理经验，负责多个敏捷项目开发和交付，体会过其中的苦和乐。对于敏捷的实施，结合团队和项目的实际情况，注重循序渐进，不追求一步到位，不拘泥于具体的方法，注重敏捷带来的价值和实际效果。目前从事Mobile Solution的工作，希望能和大家多多交流。
