由于组织从传统的预测项目管理实践转变为敏捷的产品交付实践，因此有许多误解。其中一些误解是：

“We don’t need documentation, we’re agile!”

“We can’t tell you what you are going get until we deliver, we’re agile!”

“我们不需要计划，我们很敏捷！”

尽管这些误解中的许多误解在组织通过培训和教练的敏捷转型中得到了解决，但我经常遇到一种误解，这种误解常常不再陷入敏捷的转变中。

“我们不需要风险管理，我们很敏捷！”

这种误解并不总是大声说出来，而是在组织执行敏捷框架中得到证明。产品团队可以经历几次冲刺或增量，而无需识别，分析，跟踪和/或应对可能威胁到Sprint目标的风险。常常以“缺少目标或目标只是学习的机会，我们想快速失败”的理由被原谅。虽然这是真的，但您是否可以先做一些事情来增加通过冲刺/增量执行来实现目标或目标的可能性？

为什么我们会尽早遇到其他误解，但要等到以后才抓住这个误解？

To answer this question, we must acknowledge the hidden truth; that for the most part, organizations do not perform risk management well with traditional predicative project management approaches. Figure 1 illustrates the lost opportunities for risk identification. This is the necessary first step to perform risk management. If we do not regularly identify risks, we are not actively managing project risks.

Many projects managed using traditional techniques stress maintaining conformance to the plan developed in the Project Planning and Preparation phase of the project life cycle. Development of the plan is usually done through investment of organizational time and expertise to reduce as much uncertainty as possible, i.e. reduce/eliminate risk to produce the “perfect” plan. Any risk that cannot be eliminated is identified and tracked. Once the “perfect plan” is developed and agreed to by the Project Sponsor, the project work is performed. We all know what happens when the “perfect” plan makes first contact with reality.

偏离计划通常涉及变更控制过程。这种变更控制过程通常是一个良好的过程，涉及一定程度的严格，决策论坛和文档，最终不鼓励“完美”计划的变化。

“如果有人想改变这个计划，他们最好有良好的理由。”

Early in the project, risk management is initially carried out with gusto. Risk identification is taking place, qualitative risk analysis occurs, a risk log is developed with several obvious risks and response plans developed where necessary. The response plans that are developed are typically mitigation strategies selected to reduce either the impact of the risk or the probability of the risk occurring.

项目经理和团队在项目“雾之雾”中的某个地方开始对现实对该计划的检查做出反应。项目团队开始因意外和计划外事件而感到不知所措，在此刻做出反动决策，并放弃了风险管理的纪律，以代替“完成事情”。风险管理降级为IPT（集成项目团队）会议的最后五分钟，在该会议中，风险通常很少或根本没有讨论。

最后，我们无法有效地管理项目的风险。

Is agile any better at risk management?

An agile framework such as Scrum is structured to provide multiple opportunities to perform risk management processes (risk identification, analysis, response planning, monitoring, and controlling) and to integrate the changes directly into the flow of the product delivery. Figure 2 depicts risk management processes mapped to an agile framework.

Whereas the traditional project lifecycle has long periods of work that do not have time for review, adaptation, and adjustment of the plan, Scrum has built in points for plan adjustment and reflection on the most recent product deliveries. The iterative and incremental nature of Scrum provides perfect pause points to execute risk management processes. For example, there are daily opportunities to identify risks (during the daily scrum), and bi-weekly opportunities (during Sprint Planning, review, and retrospective) of a two-week sprint cycle.

关键区别，通常是敏捷风险管理的误解的原因是，迅速识别和管理风险作为Scrum框架的迭代和增量性质的一部分的固有能力。实际上，2020 Scrum Guide作为其基本理论的一部分解释，“ Scrum采用了一种迭代，增量的方法来优化可预测性和控制风险（Schwaber＆Sutherland，2020年）。这意味着只需遵循框架，就会管理风险。

The truth in this is “yes” risks are inherently managed through the nature of the Scrum framework, but this usually assumes a well-functioning single product team (i.e., self-organizing, transparent, good communication, customer, quality and results driven). Experience demonstrates that with a well-functioning product team, the response to risk is so fluid that it reduces the need for the monitoring, controlling, and tracking of risks through an active risk log or risk board. Most risks are directly addressed through adjustment/refinement of the Product Backlog by the Product Owner.

请记住，以上陈述包括一个功能齐全的单个产品团队的假设，并且只能减少监视，控制和跟踪风险的需求。它并没有消除需求，尤其是在提供不足功能良好的产品团队的产品时。组织在采用敏捷的早期，可能会发现利用Scrum中的暂停点来花费时间进行风险管理活动很有价值。

在通过敏捷的采用率指导项目时，我使用了用户故事中的标签或标签，将产品积压物中的项目连接到风险寄存器中的风险。尽管标签是物理板上的物理连接器，但超链接在Atlassian Jira问题的“描述”区域中同样易于插入。这些超链接可以将问题链接到项目Confluence页面（即Wiki页面）中维护的风险寄存器。此外，风险应具有相应的故事编号。这为团队提供了有关特定风险影响的用户故事的观点。这只是跟踪风险并将其连接到产品积压的一种选择。如果使用诸如Atlassian Jira之类的产品，则在Atlassian Marketplace中有几种产品可在敏捷项目中为风险管理提供开发。

As organizations begin to scale their product delivery to multiple teams, the need for risk management is increased. Risk exposure related to product or team dependencies increases as product delivery scales up. These risks are usually related to product or team dependencies and may be captured and tracked in a risk log or risk board and require risk monitoring and controlling activities. Risks, such as not having business stakeholders engaged in Sprint Reviews can increase the risk that the team is building a product no one wants or a risk of not having the visibility into the Information Security Team’s backlog/ work queue can delay the release of the product to the user community.

通过在“风险漫游”的规模敏捷框架（安全）中明确包含风险管理方法，并以“风险漫游”和纪律处分的敏捷交付框架，具有风险管理框架（安全），以其风险价值价值的生命周期方法（“疯子早期攻击风险）在产品生命周期中”）。这些框架为管理风险提供了不同的方法，并包括以不同的方式识别，分析，监视和控制风险。

当试图弄清何时以及如何将风险管理流程整合到组织的敏捷框架中时，建议首先制定风险管理的总体策略。这种风险管理策略应在投资组合或组织内的所有产品中保持一致，以支持更大的风险观点，这些风险可能会影响多种产品的交付。风险管理策略还应提供足够的纬度，以使产品经理能够在他或她认为合适的情况下将风险管理流程集成到框架中。风险管理策略不一定是正式文档，它可能就像在Wiki页面上维护的“工作协议”一样简单。

When adopting agile, include the visibility of organizational risk and the reduction of the risk to product delivery has one of the desired outcomes of the adoption strategy. Make it the mission of the Agile Coaches to embed risk management in the agile framework and have the coaches ensure that the risk management processes are carried out.

敏捷社区和论坛不经常谈论风险管理，因为敏捷者也陷入了风险误解的牺牲品。即使在缩放的敏捷框架中，风险管理有时也只有轻微的触感。一位经验丰富的敏捷教练将认识到涉及风险的场景，并将具有迅速认识到风险的响应策略，鼓励团队产生回应，并将该响应集成到产品交付流程中。

参考

Schwaber，K。，＆Sutherland，J。（2020）。Scrum指南. Scrum Guides.https://www.scrumguides.org/scrum-guide.html

免责声明：这里表达的意见仅是作者的意见，并不代表Miter Corporation或其赞助商的立场。manbetx客户端首页