理解软件开发中的不确定性：敏捷方法

对任何团队来说，确定工作优先级都是一项巨大的挑战。这可能导致无法按时交付、无法满足预期以及无法衡量项目的成功。工作优先级不明确可能会引发团队倦怠，并可能导致利益相关者失去信心。

我们中的一些人可能不幸地参与过一些项目，这些项目的交付日期非常紧迫，目标模糊，验收标准（如果有的话）也不清楚。然而，这通常会导致团队和利益相关者之间反馈和知识共享效率低下。

不确定性无处不在，对于追求高效和快乐的交付团队来说，驾驭它至关重要。不确定性可能以多种形式出现，但并非所有不确定性都会对团队产生负面影响。作为一个团队，只要你能够妥善处理并优化交付流程，就能充分利用不确定性。

什么是不确定性？不确定性是指对某个概念缺乏了解。通常，不确定性指的是未来事件的影响。你可能不确定量子物理学如何运作，不确定用户对新功能的反应，或者不确定你的业务在未来五年内将如何发展。

好的一面是，有阴影就意味着有光。最重要的是，不确定性一旦存在，就显得清晰可见。如果你了解某个主题，却对它缺乏必要的了解，你通常就知道自己一无所知。例如，如果你知道需要编写一个 OAuth2 客户端，但之前从未编写过，那么你肯定不知道该怎么做。所以，不确定性就存在。

不确定性并不意味着它会很难。有些任务你知道如何做，但实际上却非常繁琐，这种情况很常见：比如构建一个使用新查询模型的新列表页面。此外，清除不确定性后发现任务其实相当简单也很常见：比如第一次使用 Spring Security 实现基于角色的系统。

处理不确定性，我们首先应该做的就是找到一种衡量它的方法。不确定性很难用数字来衡量（很难说是3个不确定性），但你可以使用抽象和相对的测量方法，至少了解你的待办事项中哪些不确定性更大。我个人很喜欢这个方法，Business and Tech Review因为它是一个简单易懂的框架，而且非常清晰。

该框架基于以下规则：

这样，您将分配一种与不确定性相匹配的颜色。

该框架的优势之一是明确界定未知数。在定义不确定性的过程中，我们会讨论如何做事以及这样做的好处，包括技术和业务方面：保持高水平的讨论，关注问题和疑虑，并将它们记录下来。这将是扫清积压工作迷雾的第一步。

当你对某项任务不确定时，请制定一个计划来应对，并尽可能推迟任务本身。如果你的团队正在执行 Scrum 或类似冲刺的交付流程，请将任务推迟到下一个冲刺。利用当前冲刺来解答解决该任务所需的问题。一个好方法是：

我们团队最近遇到的一个情况是，需要定义如何处理外部系统中发生的事件。我们在业务和技术层面都存在不确定性。我们采取了以下措施：

我们的项目经理专注于了解我们将从这些事件中获取哪些信息，以及如何利用这些信息来满足业务需求。他们还定义了业务和跨职能需求，以便我们能够制定技术解决方案。
由于我们不知道如何构建技术解决方案，因此有几种选择（AWS SQS、AWS Kinesis 或 Apache Kafka 作为通信管道），我们收集了相关信息，并决定进行一次峰值测试来测试 AWS Kinesis，以验证它是否能够满足我们的需求。我们选择了一天进行群体编程，制定了峰值路线图，并将其时间限制在 8 小时内，并在当天结束时将我们的发现记录在 Confluence 文档中，同时记录了我们决定用作架构决策记录的技术解决方案。

这个框架（技术与业务回顾）应该根据团队进度频繁应用。在我目前的团队中，我们每月都会进行一次，有时甚至每月两次。我们也使用这个框架来确定优先级：我们优先处理真正不确定的任务，这样我们就能优先发现需求，并确保工作流程的连续性和确定性。

感谢我们采用看板，通过基于概率的预测（蒙特卡洛）和连续的任务流，我们成功做到了：

我们甚至能够以比定义任务更快的速度交付任务，每周都会对积压任务进行改进！这清楚地表明，我们需要更快地清除不确定性，因此我们花了更多时间去做这件事，团队也能够平衡自己的时间来优化工作流程的不同部分。

你怎么看？如何处理积压订单中的不确定性？