敏捷项目风险管理——识别项目中的威胁和机会
Why：为什么要讨论敏捷项目风险管理
学习Scrum Guide的方法论，可以比喻为在游泳池里面练习游泳。而运用Scrum Guide为企业在现实市场大潮中的潮起潮落中用好和解决实际项目问题确为何那么困难。总结起来因为有很多不被Scrum Guide所描述的部分其实却是非常重要的。
比如，敏捷项目风险管理，就是其中之一。
其实，敏捷的节奏性和迭代性使其非常适合于管理产品开发和相关项目中常见的各种风险。敏捷实践所带来的好处和价值不容置疑，我们不能因为它的某些缺失，而完全放弃掉，这样同样也会放弃掉敏捷所带来的好处。而是将其他的优秀管理实践结合到敏捷管理中，同时保持敏捷本身的原则不变。如何正确的将风险管理纳入敏捷项目管理，又不会破坏敏捷本身的优势，正是此文要探讨。
传统方法假设需求是定义明确和稳定的，同时风险也是可预知的，在这种条件下风险可以被传统方法所捕捉和建模。然而敏捷模式下（迭代性和快速变化）对传统的风险识别方法来说是很大的挑战。
为了有助于应对不确定性和获得预期结果，敏捷模式下的方式是这样的：
用引导工作坊、敏捷建模AM进行需求理解和细化
用原型设计、架构刺探实施探索式设计方法
用增量的方式交付解决方案
这一点在高度创新的解决方案中尤其明显。在这种模式下，客户和交付团队既要相互协作，以反复确定最终解决方案的范围和内容，同时又要应对上行和下行风险。
上行风险类似于通过持续不断的交付，不能扩大市场占有率，并获得更多的业务营销增长的风险。
下行风险类似于交付物无法实现、不能成功交付、没有达到客户预期，失去客户，最终失去市场。
然而，遍寻敏捷文献，贯穿着一种明显的倾向，就是一贯的完全专注于下行风险，而没有考虑到机会的开发和利用。这种观点单一视角的认为，风险必须需要被考虑用来暴露潜在的消极后果。此外，还有一种盛行的观点认为，有敏捷就够了，因此没有必要更明确地关注风险的识别、评估、处理和监控。
尽管如此，还是有一些方法论，例如基于动态系统开发方法（DSDM）的敏捷项目管理（AgilePM）采纳了与风险社区（Risk community）实践较为一致的风险管理方法。此外，敏捷社区（Agile community）越来越多的人认识到（就不确定性而言的）风险和学习之间的关联。
What：敏捷风险管理实践都有哪些？
在现实中，风险可能是微妙而复杂的，缺少经验的人难以对其进行识别和管理。不论选择哪一种敏捷方法，都需要敏捷风险管理以解决以下问题：
1、识别项目中的威胁和机会，以平衡期望的回报和追求回报过程中的风险。这不仅需要对项目中的风险偏好和承受能力有一个彻底的了解，还需要对各个团队成员的风险倾向以及社会文化因素对风险管理的影响有所认识。
2、基于风险暴露（敞口）并通过与敏捷实践相一致的方式辨识适当的风险应对策略，并对风险应对策略进行优先级排序，例如，接受、缓解、利用。
敏捷对传统项目管理风险识别实践的借鉴和移植，可以专注于透明化，可视化，信息共享，权责共享，自组织。
敏捷实践中，对风险应对策略有：
1）在Product Backlog中纳入风险应对的相关任务。
2）使用风险缓解看板，风险缓解看板是一种计划工具，其中各种活动在代表不同阶段的各泳道之间移动，这些泳道分别对应计划、进行中、已完成。
3）用户故事地图（后面还会提到）
能够通过对风险的监控判断风险是否被有效和高效的方式管理。这也包括意识到迭代层的残余风险，以及这些残余风险如何影响项目的整体风险。
因此，无论以何种形式出现，敏捷风险管理都是敏捷项目治理的基础。在敏捷环境下，敏捷风险管理可以理解为推动风险的可视化，确保与风险相关的集体所有权和问责制，并在往往是按以人为本的原则建立的环境中为知情决策提供支持（例如，集体主义、自组织和自我授权）。
虽然敏捷实践者常常能说出他们基于什么在工作（例如，用户故事）、适用哪些质量标准（例如，“ 已完成”的定义），然而他们很少能够说清楚他们的工作对整体项目风险有何影响，或者他们为风险管理做出了何种贡献。
为了保证团队异质性、高效反馈回路和精益决策的价值不被侵蚀，将成熟的风险管理技术集成到敏捷项目需要谨慎。因此，有必要采用与敏捷宣言中的偏好和原则相一致的风险管理方法，而不是简单地将传统的风险实践嫁接到敏捷过程。事实上，经验表明，使用通常存在于敏捷项目中的工件（例如，Product backlog或Kanban），这是可能实现的。
When：什么时候实施敏捷项目风险识别？
风险管理可分为如下不同的阶段：
识别
评估
处理
监控
那么在敏捷实践中什么时候，又如何正确实施？
敏捷项目的节奏表明，风险的识别和评估以及风险措施的制定应一起纳入迭代计划。在以产品为导向的方法中（例如，Scrum，XP），这相当于 Sprint 计划；然而，在以项目为中心的方法（例如，AgilePM），这应该在每个时间盒（即，以启动和规划活动开始、紧随执行工作并以回顾结尾的结构化和固定时间段）的起点发生。此后，风险的处理和监控可以纳入迭代层的日常实践。
传统和敏捷项目风险管理之间的一个主要区别是，风险的所有权由项目团队成员以类似于用户故事（即敏捷需求）和相关任务分配的方式来确定。这就将风险管理者的传统角色转换为一个确保风险管理任务被关注和被实施的角色。这些功能可以很容易地通过现有的敏捷角色（例如，Scrum Master，DSDM 项目经理）承担。
风险识别与评估
由于风险和后果经常被混淆，风险的识别往往比人们想象的困难。例如，假设有一个将 Web 应用程序从物理基础架构迁移到一个虚拟基础架构的项目，其中一种担忧是该应用程序在迁移后是否仍然能被访问。许多人可能认为 Web 应用程序的不可用性是一个项目风险，但这实际上是失败迁移的后果。真正存在于不确定性中的风险是首先导致了web应用程序的不可访问（例如，关于虚拟基础架构系统设置是否正确的疑问，或者 Web 应用能否通过域名系统 [DNS] 寻址）。 风险和后果之间的这种混淆是特别有害且不易被察觉的，因为它会对风险管理活动造成误导。
鉴于围绕风险认识的微妙细节，敏捷团队的最好技巧之一是基于“是什么-为什么”的实践（图 1 ）。这就需要一个小组头脑风暴会议，以发现项目可能出现的风险问题，随后分析每件事情为什么可能会发生。前者识别后果，后者涉及风险。事实上，在讨论为什么一个事件可能会发生时，听到关于不确定性的明确陈述，这种情况并不少见。例如，在前面提到的迁移示例中，可以对 Web 应用程序的不可访问性（是什么）进行进一步分析，以揭示各种各样的风险（为什么），例如，虚拟服务器的配置或 DNS 条目的正确性，从而能够识别有意义的对策。这种方法的优点在于它的简单，特别是对于那些由于更长于多面手技能而疏于专家级风险管理实践的团队而言。此外，由于业务和技术多种多样，常见于敏捷团队的多样性可以视为寻找可能的风险的一项优势。但是，举行这类讨论会时，不要专注于纯粹的消极事件（例如，通过询问什么可能出错），而要保持讨论的开放性，以发现该项目可利用的机会。
因此在敏捷风险管理实践中，我们更多的应该关注于：
Oppotunity replace the Negative result
在“消极结果”中看到“机会”
根据传统实践，风险应被记录在风险登记簿中。然而，该工件必须始终保持可见性，其中的风险所有权属于团队成员，并与用户故事或其他敏捷项目任务一致的方式进行维护。这可以通过将风险登记簿放在所有团队成员能够访问的地方、并鼓励他们尽可能经常和尽可能早地提供反馈（例如，更新、补充、修正）来实现。
风险评估涉及对风险暴露的测定（其中 T 恤型号即可满足要求，例如，使用Small，Medium、Large和Extra Large表示量级）和基于风险所在的暴露带对风险打分（用于之后的风险监测）。这个分数需要考虑固有风险，并应包括需求或任务中涉及的内容，以及如何完成这种需求或任务（例如，使用减少风险的敏捷技术）。风险暴露也是风险优先定级的核心内容；反过来，风险优先定级也表明了为了应对项目风险而开展学习的紧迫性。如下图，风险暴露带评估和风险打分：
风险处理
风险评估提供确定风险响应（例如，避免、接受、利用）所需的输入。有些风险可以通过开展具体活动（称为敏捷风险管理中的“风险任务分配”）来解决，有些则需要关注活动所采取的方式（称为敏捷风险管理中的“风险标记”）。例如，开发产品用户界面时出现的需求风险可能会鼓励团队使用结对编程——一种两个个体协同工作的敏捷技术—— 来执行所有这类用户故事。因此，在稍后的迭代过程中，团队会识别所有受影响的活动，并将其标记以关联与该风险处理决策（例如，可能使用一个双头的图标作为视觉提示，以使用如 图 2 所示的结对编程）。
风险缓解看板会让人想到对风险相关任务进行颜色编码（例如，绿色为契机，红色为威胁），以支持风险的可视化。顺带地，这些做法也可以延伸到其他的敏捷工件，包括描述Epic和构成它们的用户故事之间关系的敏捷故事地图，如 图 2 所示。这使得风险分布展示出优质的可视化效果，甚至能检测出风险分析可能不足的地方（例如，没有明显的上行或下行风险的用户故事集）。
风险监控
在风险评估期间，用于衡量固有风险的分数可以用来构建跟踪总体风险管理工作的风险燃尽图。这个设置类似于故事点燃尽图，也向团队昭示存在一种无法完全消除的迭代剩余风险（由用户故事的累积剩余风险、策略转变、策略共享相关的风险构成）。此外，它清楚地显示出风险管理中的动态，而其他方式则可能不会如此清楚（例如，次级风险可能会导致图表上升而非下降）。在一种被称为“风险墙”的实践中，建议同时寻找风险燃尽和其他风险相关制品（如风险登记表、风险缓解看板或用户故事地图），以提高透明度，并积极征求团队反馈。
结论
敏捷得到比以往任何时候都更加广泛的应用，而其在风险管理、治理和相关事项中的位置仍然是一些组织的障碍。但是，随着这些挑战的应对措施被发现并融入敏捷方法论和项目实践中，这一点正在开始改变。这不仅提供了有关风险管理的监督和问责制，同时也保证了敏捷在就其提供的价值而言的好处方面不会受到损害。