风险管理包括风险评估、舒缓风险影响以及监控风险。很多敏捷用家相信敏捷开发项目风险管理过程跟传统项目差不多,虽然这过程在敏捷的内容中较为轻盈,但是在找寻、过滤、优先化以及制造解决方案上的步骤跟传统项目中很接近。
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图。此外,风险倍数的使用还有其他注意的地方:
其他方法如Prince2、PMBOK或CMMI等对风险管理都有值得参考之处,而跟敏捷有关的独特观点则是减少开发上浪费而没必要的过程和活动,之前在「Scrum的风险管理」也有相关的讨论。
还有,要好好管理风险,评估形势的能力很重要,甚至比其方法更重要,例如如何猜量我们是否在"风险较高进行开发"呢?这里其实可以套用Stacey模型和Cynefin模型来辅助。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/14639675/viewspace-566762/ ,如需转载,请注明出处,否则将追究法律责任。