在敏捷评估和规划中 ，迈克·科恩（Mike Cohn）引用了吉姆·海史密斯（Jim Highsmith）关于为何敏捷项目更好的原因：

“我经常告诉人们的一件事是，敏捷计划是“更好”的计划，因为它利用了功能（故事等）而不是任务。 使用标准任务计划整个项目很容易，而无需真正了解要构建的产品。 按功能计划时，团队对产品有更好的了解。”

海史密斯在Yahoo邮件小组的原始帖子中还说： “有时敏捷运动中的关键人物有时会被夸大以引起注意，我有时自己也这样做过-有点过分了以求明确。 然后人们将其抬起并推得太远。”

显然这是其中一次。

基于活动的计划与基于功能的计划

参数运行如下。 WBS和甘特图中描述的基于活动的计划是根据“标准化任务”构建的。 这些任务或活动与客户所需的功能没有直接关系，它们只是描述了开发团队需要做的技术工作，而这些工作对其他利益相关者没有意义。 根据海史密斯（Highsmith）的说法，您可以在不了解要构建的软件实际功能的前提下，也可以在不了解对客户重要的方面来制定这样的计划。

从功能待办事项列表进行工作的敏捷计划会更好，因为它“迫使团队在正确的级别上考虑产品-功能”。

我认为我没有从事过软件开发项目，没有以任何方式计划，没有考虑和计划客户想要的功能。 我们没有跟踪和管理设计，构建和交付具有这些功能的软件所需的活动，其中包括幕后的工程工作和繁重的工作：定义架构，设置开发以及构建和测试环境及工具，评估和实施或构建框架和库以及其他管道，定义API并注意与其他系统和数据库的集成，安全工作和性能工作以及运营工作和系统以及集成测试，尤其是处理外部依赖项。

这项工作中的某些对客户而言毫无意义。 这不是功能列表中捕获的工作。 但这并不意味着您应该假装不需要做，也不意味着您不应该在计划中跟踪它。 良好的项目计划可以明确显示客户关心的功能以及何时进行工作， 以及需要完成的重要技术工作。 它必须反映团队的想法和工作方式。

基于活动的计划在很多方面都是错误的

在第一章的“为什么计划失败”一章中，科恩列举了基于活动的计划的弱点。 首先，大多数基于活动的计划者都不会根据客户的需求确定需要完成的工作的优先级。 这是因为他们认为范围中的所有事情都需要并且将要完成。 因此，以一种方便开发团队的方式安排活动。 这意味着，当团队不可避免地意识到他们超出预算并且无法按时完成计划时，他们将不得不削减对客户重要的功能-比他们已经在浪费时间的工作更重要。

也许。 但是，没有什么可以阻止使用基于活动的计划的团队按照客户的优先级，技术依赖性和技术风险对工作进行排序的方法， 而这正是包括敏捷团队在内的所有团队所要做的。 这是团队遵循螺旋生命周期时的工作方式，以及使用分阶段/分期交付以增量版本交付工作的团队，或按计划进行设计和建造的团队，以确保他们尽早完成高优先级工作，以便到达了一个艰难的截止日期 所有这些都是众所周知的软件项目计划和交付方法，在Steve McConnell的Rapid Development和其他书籍中都有介绍。 我认识的每个以“传统，计划驱动”方式交付项目的人都遵循这些方法之一，因为他们知道，纯净，幼稚，计划前的串行瀑布模型在现实世界中不起作用。 所以我们可以别再假装了。

对基于活动的计划的另一种批评是，不可能准确，有效地提前定义软件开发项目的所有工作和所有详细的依赖关系。 当然不是。 这就是Rolling Wave计划的目的–列出主要的项目里程碑，阶段和依存关系，并计划下一个版本或未来几个月/几周/未来的详细计划。 尽管Cohn在敏捷项目的背景下很好地解释了Rolling Wave计划，但是很长一段时间以来，它一直是任何项目公认的良好计划实践。

敏捷计划不是更好，因为它们基于功能

这些以及本书中其他反对基于活动的计划的论点，都是Glen Alleman完美描述的一种疲惫的修辞技巧的例子：

“讲一个关于某人故意做愚蠢的事情的故事，然后举例说明如何使用敏捷方法纠正结果”。

当然，很多Waterfall项目都无法正常运行。 而且，是的，可以肯定的是，一个敏捷项目有一个更好的机会来接替一个计划不周，管理不善的连续瀑布项目。 但这不是因为敏捷计划基于功能或基于活动的计划是错误的。 无论他们采用哪种方法，人们都可以做愚蠢的事情。 敏捷计划的真正力量在于明确地识别变化并通过短迭代不断地管理不确定性和风险。 幸运的是，这就是科恩书中其余部分的内容。

参考： 敏捷计划是否更好，因为它们基于功能？ 来自JCG合作伙伴 Jim Bird在Building Real Software博客上的介绍。