传统需求 vs. 敏捷需求

项目旨在实现客户的需求，这些需求通过用户故事、智能用例或功能等任务项进行详细说明。这些任务项构成了项目的待办事项列表。

与传统项目类似，敏捷项目中的需求也会经历多个阶段，每个阶段都包含不同的活动。在两种类型的项目中，都会对需求的分析、设计、开发、测试和验收进行考虑。然而，传统方法与敏捷方法之间最大的区别并不在于需求如何细化，而在于需求在何时被细化。

我们将基于一个简单的计算来比较两种方法的有效性。

传统项目中的需求

传统项目从需求的详细化开始，直到所有需求完整且详尽为止。所谓“完整”，意味着所有需求都已明确；所谓“详尽”，意味着所有必要细节均已描述清楚。传统做法的目的在于建立一种安全感，因为需求是估算项目成本和工期的基础。这一详细化的需求集合最终形成项目计划。

在传统的项目方法中，项目初期就投入大量时间用于需求的细化。假设某个项目有100个需求，每个需求需要20小时进行细化，那么团队总共将耗费2,000小时来完成需求的细化工作。

虽然许多组织认为这是一种高效的方法，能够大幅减少项目不确定性，但实际情况恰恰相反。仍存在一些不可忽视的风险因素：

• 知识不足：要在项目早期就达到如此高的细节程度，需要大量的前期知识积累。然而，这种知识往往在项目初期尚未充分发展。因此，早期细化需求所花费的时间远超后期再进行相同工作的所需时间。
• 需求不清晰：在项目初期，许多需求本身尚不明确。客户还无法对如此多的细节做出决定。

在一个敏捷项目中，我们正在实现超过300个智能用例。该项目已运行两年，至今仍有部分智能用例无法确定具体细节，必须经过充分准备后才能明确。显然，在项目启动之初，这是不可能做到的。

• 需求变更：众所周知，无论采用瀑布模型还是敏捷方法，项目过程中需求都会发生变化，这是不可避免的。会出现新的需求，原有需求的理解也会不断深化，甚至有些需求会变得过时。研究表明，平均有20%到25%的需求会发生变化。以本例为例，这意味着至少有四五百小时的工作量将被浪费。

因此，在项目早期就将需求细化到如此高度，并非一种有效的方式。更重要的是：我们真的需要这么高的细节程度吗？

敏捷项目中的需求

敏捷项目对需求的处理方式截然不同。大部分关于需求的工作并非在项目初期完成，而是在需求真正需要时才进行。这发生在两个关键节点：

• 估算阶段：在项目初期，我们只需确定需求的规模，以便给出初步估算。这并不需要太多细节，仅需能识别出需求即可。
• 实现阶段：只有当需求被选为迭代中的工作项时，才真正需要详细信息。此时，需求才会被进一步细化，做到“按需即时”（just-in-time）。

这是一种全新的需求管理思路。这一原则可以用缩写 YAGNI 来表达，即“你不会需要它”（You Aren’t Gonna Need It）。简而言之，就是当前不需要的工作，就不应该现在去做。

敏捷项目只在真正需要时才对需求进行细化。在本例项目中，项目初期仅对已识别的需求进行必要的细化，以支持估算工作。相比传统项目，所需的细节大大减少。例如，传统项目可能每个需求需耗时20小时，而敏捷项目可能只需4小时。只有当某个需求被选入迭代并即将实现时，才会进一步细化，确保具备足够的实现细节。这种方式带来了显著优势：

• 渐进式洞察：直到细化时刻为止获得的所有新认知都能自动融入其中。无需填写变更请求单，也不存在项目结束后才进行实现的情况。
• 知识积累：随着项目推进，客户和团队对领域、技术手段及技术架构的理解不断加深。这种知识积累使得后期需求细化所需时间更短，调查内容更少。因此，每个需求的详细细化可能仅需8小时左右。
• 确定性更高：当需求在迭代中被选定，就意味着它一定会被实现。相比之下，传统项目中即使需求被详细定义，也可能因项目变动而从未被实现。而敏捷项目中，只有确定要实现的需求才会被细化。

综上所述，无论是传统项目还是敏捷项目，最终都需要完成相同的工作量来细化需求，但执行时机却大相径庭。在我们的示例计算中，敏捷项目每个需求可节省8小时。

注意：此例虽为虚构，但完全符合现实情况。这样，渐进式洞察反而成了推动项目前进的力量。