规划：风险管理以管理不确定性

许多组织计划创建确定性和各种保证。如果我们考虑将敏捷计划作为一种管理不确定性的方法怎么办？

当我查看包含所有“必须执行”功能集的漫长路线图以及管理人员施加于团队以交付的压力时，我想知道以下问题：

我们对要解决的问题的了解程度如何？

我发现这些问题对我有帮助：

我们对问题的了解越少，我们就需要进行更多的实验。我们越需要实验，就越需要滚动波计划。

我们将滚动波计划用于从这些实验中学习和反馈的次数越多，故事的规模就越小。这样我们就可以获得反馈。

故事越小，我们更新计划的频率就越高。我们越频繁地更新计划，就越能为近期创建更牢固的路线图，并为长期创建更多由假设驱动的路线图。（请参阅敏捷和精益路线图系列。）

为了准备在Agile 2018上的演讲，我创建了此表来说明并非每个问题集都相同：

最左边的一栏是关于易于理解的问题。如果我们很好地了解了客户问题，我们也许可以计划（并执行）六分之四的路线图。

创建路线图，填充路线图（以某种方式提交）等相对容易。这是因为问题不会改变。

在管理层希望团队打破物理定律的过程中，我们可能仍然存在问题，但这实际上是一个可管理的问题。（在某些时候，拒绝女王承认现实。）

在中间一栏中，如果我们大多数情况下都了解问题，也许我们使用的范围有限，并期望使用具有MVP或某些最低要求的滚动计划。我们需要反馈来完善我们的计划。（我碰巧更喜欢三个月的滚动浪潮，但这可能不足以满足您的计划。）

这里的风险是，问题的变化比我们的滚动波和交付速度更快。您可以“保证”或承诺任何事情吗？您可能会，尤其是如果您承诺不超过一个月的工作。（即使是一个月，我也不乐观，但这取决于产品。）

现在，在最右边的表格中，我看到许多组织都在渴望担保而不是管理不确定性。当我们有很大的不确定性时，我希望有一个关于“大创意和实验”而不是功能集的“路线图”。我喜欢一个月的滚动浪潮，看看我们可以将这些“大创意”和“实验”做多小。（是的，我需要为此创建一个图像。）

敏捷方法适用于大多数“理解的”和“根本不理解的”问题，因为我们需要查看进度并验证进度是否可以解决各种问题。

如果我们有明确定义的不变客户问题，那么我们就不需要敏捷方法。我们可能会使用敏捷方法来帮助每个人了解我们的进步，但是我们不需要敏捷方法。

我们越需要反馈来指导我们的未来计划，我们就越需要敏捷方法。这意味着即使在路线图级别，也可以采用敏捷的计划方法，以便我们可以管理而不是消除不确定性。

翻译自: https://www.javacodegeeks.com/2018/08/risk-management-manage-uncertainty.html