项目风险是一种不确定的事件或条件,一旦发生,就会对项目目标造成积极或消极的影响。
现实中,风险可能是微妙而复杂的,缺少经验的人很难对其进行识别和管理。
敏捷风险管理是敏捷项目治理的基础。在敏捷环境下,敏捷风险管理可以理解为推动风险的可视化,确保与风险相关的集体所有权和问责制,并在以人为本原则建立的环境中为决策提供支持。
风险识别与评估
风险和后果经常被混淆。因此,风险的识别往往比人们想象的困难。
例如:
有一个将 Web 应用程序从物理基础架构迁移到虚拟基础架构的项目。项目面对的一个担忧是“该应用程序迁移后是否仍然能被访问?” 大部分人认为 Web 应用程序的不可用性是一个项目风险,但这实际是迁移后的失败后果。真正存在的不确定风险是“什么导致了web应用程序不可访问?” 如:虚拟基础架构系统设置是否正确?或者 Web 应用能否通过域名系统 [DNS] 寻址?
风险和后果之间这种混淆不易被察觉,并对风险管理活动造成误导。对于围绕风险认识的微妙细节,敏捷团队的最好技巧之一是基于:
“是什么-为什么”实践
用小组头脑风暴会议,发现项目可能出现的风险问题,随后分析每件事情为什么可能会发生。是什么识别后果,为什么涉及风险。
在讨论为什么一个事情可能发生时,常常会听到关于不确定性的明确陈述见。例如:
迁移案例中,对 Web 应用程序不可访问(是什么)进行进一步分析,会发现各种各样的风险(为什么)。 如:虚拟服务器的配置或 DNS 条目的正确性。
从中也能够识别有意义的对策,这种识别方法很简单,特别是对于团队而言。但是,举行这类讨论会时,不能专注于纯粹的消极事件(例如:什么可能出错)。而应该保持讨论的开放性,发现项目可利用机会。
风险应该被记录在风险登记簿中,与用户故事或其他敏捷项目任务用一致的方式进行维护。将风险登记簿放在所有团队成员能够访问的地方、并鼓励他们经常、提前提供风险反馈(如:更新、补充、修正)来实现风险管理
风险类型
软件开发分为开发人员、过程、产品和技术4个维度,互相联系和统一,共同决定了软件开发的速度和效率。
而项目风险对应这4个维度,分别存在4类风险
-
人员风险
人员风险包括:沟通不畅,缺乏协作,人员变动,素质低下,矛盾和冲突,缺乏激励,士气低下,对业务不理解,缺乏优秀人才,缺乏客户介入等。
-
技术风险
技术风险包括:伪敏捷,架构体系不稳定,设计不佳,缺乏技能,高估新技术等。
-
产品风险
范围风险包括:功能不符,需求镀金,功能蔓延,质量低下,工期延误,成本超支,客户满意度低,低产品价值,低投资回报等。
-
过程风险
过程风险包括:缺乏计划,迭代掌握不佳,评估和规划不合理,缺乏风险管理,缺乏质量保证措施等。
敏捷软件开发的风险处理方法
敏捷软件开发过程中,主要从人、过程、产品和技术四个纬度进行的风险处理过程。
1. 人员风险
↘ 敏捷软件开发管理通过频繁沟通、每日站立会议、反馈等方式解决沟通不畅,缺乏协作的问题;
↘ 通过领导、结对编程、代码集体所有权等方式促进团队协作,也可以很好地应对人员离开带来的风险;
↘ 通过频繁的产品发布提高人员成就感和士气;
↘ 通过现场开发,降低缺乏客户介入的风险;
↘ 通过敏捷开发团队注重培养,当敏捷团队中出现人员流动的情况下,就会有很多后备人才可以承担他留下的工作。用T字型人才以缓解人员风险。
T字型人才,指团队成员对开发过程的某一领域具备较深的造诣,在其他相关领域也具备一定能力。 如:一个有经验的软件编码人员同时具有详细设计和测试的能力。
2. 技术风险
敏捷软件开发通过迭代、测试套件、重构等方式适应变化和演进,避免了传统的开发方法在一开始就进行架构及设计,导致架构体系不稳定和设计不佳的风险。
对敏捷技能险,通过引入敏捷教练、结对编程、学习环的方式应对。
而非敏捷软件开发特有的普适性技术风险,可以通过组织和加强内部技术人员的培训和培养,引进能解决项目关键问题的优秀人才,防止优秀人才的流失等方式规避。
3. 产品风险
敏捷软件开发通过迭代、反馈、客户参与的方式解决“构建错误产品、功能蔓延、需求镀金、质量低下、客户满意度低”等风险。
通过综合考虑功能的价值和风险,按照“高风险高价值→低风险高价值→低风险低价值→高风险低价值”的顺序开发产品功能,渐次降低价值风险;
通过对净现值、内部收益率、回收期、贴现回收期等经济指标的综合分析,规避项目的投资回报风险。
4. 过程风险
进度风险的缓解方法包括:
-
迭代计划会议:敏捷开发是多个迭代周期依次进行的,每个迭代周期时间都不长。因此,风险可以及时发现、及时处理。
而且,迭代周期内出现意外、变更或其它风险,也会在下个迭代处理。只要在迭代计划会议上定出合理的迭代计划,团队就可以按照开发节奏推进项目,避免被意外打乱计划。
-
估算团队速率:团队速率影响迭代计划和版本计划的可行性。
敏捷迭代都要完成需求、设计、实现、测试活动,不同的是完成的需求不同;在经历1~2个迭代后,可以得到比较真实的团队速率。
-
现场用户交流:软件开发人员和作为用户代表的产品经理实时进行交流,一起对需求进行细化,排定需求的优先级。
这样做很大程度避免了在开发过程中出现影响进度的需求变更。
-
缺陷清除前移:敏捷的每个迭代都会进行测试活动,这样做可以有效减少项目后期遗留缺陷,进度更加可控。
功能和进度风险保护:
-
设置功能缓冲区和进度缓冲区,从功能和进度两个方面保护项目免受不确定性的冲击。
-
从3个方面对进度风险进行定量分析:
a) N=S/V,估算的项目总迭代数(S:项目的总故事点数,V:速率,基于历史数据计算的每一次迭代所能完成的故事点数)
b) 用正态分布N(μ,σ的平方),得到每一次迭代的平均故事点数X和标准差σ,计算μ=(S/N-X)/σ,并得出项目按时完成的概率
c) 综合正态分布,PERT分布,三角分布进行蒙特卡罗模拟,得出模拟的结果并绘制累计完成的概率分布。