敏捷实践的内在节奏和迭代特性使其非常适合于产品开发及相关项目中多种常见风险的管理。1 确实，此类项目经常需要各种不同性质的修改并有不同的时间要求。而传统管理方法认为必要条件要求都可以明确设定且状态稳定，已知风险可以由传统技术描述和建模。这种不断的改变对传统管理方法是很大的挑战。例如，敏捷管理方式对各种条件要求不断加深理解的方式（例如，组织和推动各种研讨会、敏捷建模）、在探索中进行设计的方法（例如，原型设计，建筑尖峰）和解决方案的增量交付都有助于应对不确定性和获得预期结果。这一点在高度创新的解决方案中尤其体现。在这种方案中，客户和交付团队既要相互协作，以反复确定最终解决方案的范围和内容，同时又要应对上行和下行风险。
然而，在敏捷文献中，贯穿着一种明显的倾向，即完全专注于下行风险，而没有考虑到可以开发和利用的机会。不难理解，众多的方法论明确表示风险应被认为有可能带来负面的结果。此外，还有一种流行的观点认为，有敏捷就够了，不需要更明确地注意风险的识别、评估、处理和监控。
尽管如此，还是有一些方法论，例如基于动态系统开发方法（DSDM）的敏捷项目管理（敏捷 PM）2 采纳了与风险社区实践较为一致的风险管理方法。3 此外，敏捷社区越来越多的人认识到风险（就不确定性而言）和学习之间的关联。4
在现实中，风险可能是微妙而复杂的，缺少经验的人难以对其进行识别和管理。不论选择哪一种敏捷方法，都需要敏捷风险管理以解决以下问题：
- 识别项目中的威胁和机会，以平衡期望的回报和追求回报过程中的风险。这不仅需要对项目中的风险偏好和承受能力有一个彻底的了解，还需要对各个团队成员的风险倾向以及社会文化因素对风险管理的影响有所认识。
- 基于风险暴露并通过与敏捷实践相一致的方式（例如，在产品订单中纳入风险相关任务，或者使用风险修改看板——一种计划工具，其中各种活动在代表发展阶段[例如，计划、进行中、已完成]的巷道和用户故事地图[本文稍后描述]中活动），确认适当的风险应对策略（例如，接受、减轻、开发）并对其进行优先排序。5
- 通过风险监控判断风险是否被有效和高效的方式管理的能力。这也包括迭代层次的残余风险意识，以及这些如何影响项目的整体风险 程度。
因此，无论以何种形式出现，敏捷风险管理都成为项目治理的基础。在敏捷环境下，这被解释为推动风险的可视性，确保与风险相关的集体所有权和问责制，并在往往是按以人为本的原则建立的环境中为知情决策提供支持（例如，集体主义、自我组织和自我授权）。
敏捷式风险管理方法
虽然敏捷实践者常常能说出它们在做什么（例如，用户故事）、适用哪些质量标准（例如，“ 已完成”的定义），有说他们很少能够说清楚他们的工作对整体项目风险有何影响，或者他们为风险管理做出了何种贡献。
为了保证团队异质性、高效反馈回路和精益决策的价值不被侵蚀，将成熟的风险管理技术集成到敏捷项目需要小心。因此，有必要采用与敏捷宣言中的偏好和原则相一致的风险管理方法，而不是简单地将传统的风险实践嫁接到敏捷过程。事实上，经验表明，使用通常存在于敏捷项目中的制品（例如，产品订单或看板），这是可能实现的。如 图 1 所示。
敏捷项目的自然节奏表明，风险识别和评估以及风险措施的识别应一起纳入迭代计划。在以产品为导向的方法中（例如，Scrum，XP），这相当于 Sprint 计划；然而，在以项目为中心的方法（例如，AgilePM），这应该在每个时间盒（即，以启动和规划活动开始、紧随执行工作并以回顾结尾的结构化和固定时间段）的起点发生。此后，风险的处理和监控可以嵌入迭代层次的日常实践。
传统和敏捷项目风险管理之间的一个主要区别是，风险的所有权由项目团队成员以类似于用户故事（即敏捷要求）和相关任务分配的方式来确定。这就将风险管理者的传统角色转换为一个更具促进性从而确保对风险管理的注意力的角色。这些功能可以很容易地通过现有的敏捷角色（例如，Scrum Master，DSDM 项目经理）承担。
风险识别与评估
由于风险和效果经常被混淆，风险的识别往往比人们想象的困难。6 例如，假设有一个将 Web 应用程序从物理基础架构迁移到一个虚拟基础架构的项目，其中一种担忧是该应用程序在迁移后能否访问。许多人可能认为 Web 应用程序的不可用性是一项项目风险，但这实际上是失败迁移的效果。真正的风险在于导致 Web 应用从一开始 就不可访问的不确定性（例如，关于虚拟基础架构系统设置是否正确的疑问，或者 Web 应用能否通过域名系统 [DNS] 寻址）。 风险和效果之间的这种混淆是特别有害且不易被察觉的，因为它会误导风险管理活动。
鉴于围绕风险认识的微妙细节，敏捷团队的最好技巧之一是基于“是什么-为什么”的实践（图 1 ）。这就需要一个小组头脑风暴会议，以发现项目可能出现的风险问题，随后分析每件事情为什么可能会发生。前者识别效果，后者涉及风险。事实上，在讨论为什么一个事件可能会发生时，听到关于不确定性的明确陈述，这种情况并不少见。例如，在前面提到的迁移示例中，可以对 Web 应用程序的不可访问性（是什么）进行进一步分析，以揭示各种各样的风险（为什么），例如，虚拟服务器的配置或 DNS 条目的正确性，从而能够识别有意义的对策。这种方法的优点在于它的简单，特别是对于那些由于更长于多面手技能而疏于专家级风险管理实践的团队而言。此外，由于业务和技术多种多样，常见于敏捷团队的多样性可以视为寻找可能的风险的一项优势。但是，举行这类讨论会时，不要专注于纯粹的负面事件（例如，通过询问什么可能出错），而要保持讨论的开放性，以发现该项目可能利用的机会。
根据传统实践，风险应被记录在登记簿中。然而，这种制品必须始终保持可见性，其中的风险所有权必须由团队成员以与用户故事或其他敏捷项目任务大致相同的方式承担。这 可以通过保持登记簿在所有团队成员能够访问的地方、并鼓励他们尽可能经常和尽可能早地提供反馈（例如，更新、遗漏、更正）来实现。
风险评估涉及确定面临的风险（其中 T 恤型定型即可满足要求，例如，使用小，中和大表示幅度）和基于风险所在暴露段对风险打分（用于之后的风险监测）。这个分数需要考虑固有风险，并应包括要求或任务中涉及的内容，以及如何完成这种要求或任务（例如，使用减少风险的敏捷技术）。面临的风险也是风险优先定级的核心内容；反过来，风险优先定级也表明了为了应对项目风险而开展学习的紧迫性。
风险处理
风险评估提供确定风险响应（例如，避免、接受、利用）所需的输入。有些风险可以通过开展具体活动（称为敏捷风险管理中的“风险任务分配”）来解决，有些则需要关注活动所采取的方式（称为敏捷风险管理中的“风险标记”）。例如，开发产品用户界面时出现的要求风险可能会鼓励团队确保使用结对编程——一种两个个体协力工作的敏捷技术—— 来执行所有这类用户故事。7 因此，在稍后的迭代过程中执行活动时，团队会确定所有受影响的活动，并将其标记为这个决定的提醒（例如，可能使用一个双头的图标作为视觉提示，以使用如 图 2 所示的结对编程）。
风险修改看板会让人想到对风险相关任务进行颜色编码（例如，绿色为契机，红色为威胁），以支持风险的可视化。顺带地，这些做法也可以延伸到其他的敏捷制品，包括描述 叙事诗和构成它们的用户故事之间关系的敏捷故事地图，如 图 2 所示。这使得风险分布实现优质的可视化，甚至能检测出风险分析可能不足的地方（例如，没有明显的上行或下行风险的用户故事集）。
风险监控
在风险评估期间，用于衡量固有风险的分数可以用来构建跟踪总体风险管理工作的风险燃尽图。这个装置类似于广泛使用的故事点燃尽图，也向团队昭示存在一种无法完全消除的迭代剩余风险（由用户故事的累积剩余风险以及与转移或共享战略相关的风险构成）。此外，它清楚地显示出风险管理中的动态，而其他方式则可能不会如此清楚（例如，次级风险可能会导致图表上升而非下降）。在一种被称为“风险墙”的实践中，建议同时寻找风险燃尽和其他风险相关制品（如风险登记表、风险修改看板或用户故事地图），以提高透明度，并积极征求团队反馈。
结论
敏捷得到比以往任何时候都更加广泛的应用，而其在风险管理、治理和相关事项中的位置仍然是一些组织的障碍。但是，随着这些挑战的应对措施被发现并融入敏捷方法论和项目实践中，这一点正在开始改变。这不仅提供了有关风险管理的监督和问责制，同时也保证了敏捷在就其提供的价值而言的好处方面不被侵蚀。
尾注
1 Moran, A.；敏捷风险管理施普林格出版社，德国，2014 年
2 DSDM财团，DSDM敏捷项目框架，2014 年
3 Op cit， Moran
4 Cockburn，A.；“早学、勤学”如何让我们不止于降低风险人与技术，2013 年 2 月，http://alistair.cockburn.us/Disciplined+Learning
5 Op cit, Moran
6 Hillson, D.；在项目中管理风险，高尔出版社，英国，2009 年
7 敏捷联盟，敏捷实践指南，2015年， http://guide.agilealliance.org/
Alan Moran，博 士，CRISC，CITP 是一位敏捷思想领袖和敏捷管理研究所的董事总经理。他的职业生涯跨越私营和公共部门，他的研究兴趣在于敏捷管理（例如，风险、财务和治理）以及敏捷企业。他经常受邀在国际会议上演讲，撰写了敏捷风险管理，管理敏捷：战略、组织、实施和人 （施普林格出版社），重视敏捷：敏捷项目财务管理。