有一件事是可以肯定的，即敏捷方法并不能解决业务中的根本性问题，尤其是当业务本身不能决定如何做，或无法决定优先级时，敏捷方法根本帮不上忙。

几乎同时，JavaEye出了一个题为“XP or not” 的帖子，提出了几乎同样的观点。这位作者说“XP isn't suitable for every type of software development, it has its own suitable area”，显然这是毋庸置疑的事实，我们甚至用不着为此进行讨论。我们应该做的是，找出敏捷方法（具体说，XP）为什么和如何不适合产品开发，并且找出改进的方向。正如我在InfoQ那篇新闻下面回复的，

对于产品研发，只有敏捷是不足够的。敏捷能做出你想要的，但没办法保证做出好的或者正确的或者受欢迎的。而且作为从内部IT项目衍生而来的敏捷方法，它本身有一种趋势：把功能做到能用而非完美。对于内部IT项目，这很好，两个能用的功能往往能提供比一个完美的功能多得多的价值；但对于面向公共用户的产品，你麻烦了，因为不完美的功能很可能根本就没人用。

王晓明显然经过和我在飞机上的讨论有了很多想法，并且这些想法看起来相当靠谱。问题的根源就在于：面对企业内部用户和面对公众用户，概念完整性的估价（priority）是完全不同的；同样，还有可用性——千万不要误会，我并不是打算说敏捷项目一定忽视概念完整性或者可用性。只是很多敏捷团队的经验来自类似C3项目这样的企业内部IT项目，他们的经验蒙蔽了他们的双眼，让他们看不到各种软件特性估价的变化。这个问题是比较容易解决的，只要意识到不够好用的功能将没有人用因此无法创造任何价值，他们就会重新调整自己对于各种软件特性的估价，因为敏捷的核心就在于价值驱动。

不那么容易解决的问题是方法和工具的欠缺。这也就是为什么我说“只有敏捷是不足够的”。譬如说为了提高可用性我们就需要交互设计。还有很多类似这样的、适用于产品开发的方法和工具，它们从不同角度影响软件特性。敏捷能做出你想要的，但如果只有敏捷而缺乏这些方法和工具，很可能你永远不知道自己究竟想要什么。然而更严重的问题是看待这些方法和工具的态度，

交互设计是改进的办法之一。但很多敏捷的组织对此认识并不充分，他们只是在项目进行中让交互设计师来做一 次评估和设计。这是不足够的，就好像在软件项目的交付之前才进行QA工作是不足够的一样。质量来自整个流程，同样好的交互设计也来自整个流程。

敏捷团队都充分地意识到，质量保证必须贯穿整个流程进行，这是敏捷方法带来更高软件质量的根本原因所在——测试驱动和持续集成当然是很好的实践，但这些实 践能够得以工作，是因为我们在流程层面对质量的重视。而对于概念完整性、可用性和其他软件特性，我们有类似这样的流程层面的重视吗？正如我在InfoQ的 回复里说的，有了敏捷方法，还要有一套全流程的产品设计方法支持，才可能做出好的产品。这就是我们要去学习和探索的方向。