敏捷风险管理

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

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"一文）的情况下使用以下的风险倍数。

风险倍数

机会率	精确的开发过程所使用的倍数	內容
10%	1	几乎没可能
50%	1.4	伸延目标--只得一半机会，有机会再去完成
90%	1.8	几乎可以成事的承诺

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

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

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

机会率	能完成的故事点数	內容
10%	140 (140 ÷ 1)	几乎没可能
50%	100 (140 ÷ 1.4)	伸延目标--只得一半机会，有机会再去完成
90%	78 (140 ÷ 1.8)	几乎可以成事的承诺

从以上例子中：

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

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

查看英文原文：Agile Risk Management

译者附注：

James的网站有更多关于其风险倍数的内容，亦可参考他所写的"The Art of Agile Development"一书，特别是此文没有包括的Burn-up图。此外，风险倍数的使用还有其他注意的地方：

• 「承诺」背后的意义，值得思考的就是「承诺」到底是什么、管理人员如何理解和使用这里作出的「承诺」。要知道，这些还是机会率，如果最后变成合约，又或者客户拿来争议的「论点」，那么也是没有意思的。
• 风险倍数的由来，这里的1、1.4和1.8是如何得出呢？到底又有多适合您的项目情况呢？就连James自己的网页上 也有这样一句 "I'm guessing somewhat at how accurately they apply to XP. The most accurate approach is to calculate your own risk multipliers from past project history, but most companies don't track that data" （我在猜这些数字对极限编程的情况有多准确，最准确的方式还是根据过往项目纪录来计算您的风险倍数，但很多公司根本不会记下这些数据），所以千万不要把这 些数字看成什么魔幻数字。
• 延续上面这点，如果公司为了提供「承诺」而去收集项目相关数据，这是否对容户有所得益呢？容户为什么要投资金钱给开发公司去收集数据？客户又如何可以知道投资金钱让公司收集这些数据可以有所回报呢？

其他方法如Prince2、PMBOK或CMMI等对风险管理都有值得参考之处，而跟敏捷有关的独特观点则是减少开发上浪费而没必要的过程和活动，之前在「Scrum的风险管理」也有相关的讨论。

还有，要好好管理风险，评估形势的能力很重要，甚至比其方法更重要，例如如何猜量我们是否在"风险较高进行开发"呢？这里其实可以套用Stacey模型和Cynefin模型来辅助。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14639675/viewspace-566762/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14639675/viewspace-566762/