特性专注

敏捷方法中一种常见且可能占主导地位的做法是为正在构建的软件开发一份特性列表（通常称为故事）。这些特性使用索引卡、工作队列、燃尽图、待办事项列表或您选择的任何工具进行跟踪。

总的来说，我喜欢这种方法。通过将您需要做的所有事情分解成可以在一周或几天内完成的小任务，您可以可视化进度并了解您可以完成多少工作。我经常说，迭代开发的主要好处是通过强制完成软件块来降低风险，而不是像瀑布式开发那样将漫长且难以管理的活动（测试、集成）留到项目后期。

问题在于，当这份列表突然长出犄角和獠牙，变成一份固定价格、固定范围的大型前期项目计划时。Craig Larman 曾经开玩笑说，瀑布式流程具有强大的抗体，可以通过将迭代流程扭曲成某种形式的瀑布式流程来排斥它们。RUP 一直是这些抗体的常见受害者，其阶段变成了某种形式的分析-设计-构建-测试传送带。

战胜瀑布式开发的关键在于认识到，正如 Dan 所说，敏捷主义者重视结果而非特性。特性列表是一个有价值的工具，但它是一种手段而不是目的。真正重要的是整体结果，我认为这是对客户的价值。

这种想法的一个重要部分是，您预计特性列表会随着项目的进行而发生变化。当您发现可以做的新事情并重新确定旧事情的优先级时，就会发生这种情况。这是自适应计划的本质，它一直是敏捷思维的关键指标。这导致人们对计划的看法发生了巨大变化。在计划驱动的项目中，成功和失败通常用“事情是否按计划进行？”来表述。在敏捷项目中，这是一个毫无意义的问题，因为计划经常变化。计划是一种工具，主要用于衡量变更的影响：“添加此特性将如何影响我们的工作”。计划是一种工具，用于确定哪些内容应该放在五磅袋中。如果您的计划没有不断变化，那么您就不太可能在进行自适应计划，因此也不是敏捷的。

特性列表还有另一个问题——您很容易忽略使特性有价值的上下文。这就是 Alistair Cockburn 支持用例的原因，因为用例侧重于描述某人如何使用系统的叙述。Marc NcNeil 也从客户旅程的角度谈论了这一点。用例在计划中的弱点在于，它们没有为您提供明确的勾选单元，因此您无法评估进度并将选择的后果预测到未来。这使得它们作为计划工具的用处不大，但这并不能否定它们作为想象良好结果的工具的价值。