产品研发中的敏捷:不足与方向

(查看原文: http://gigix.thoughtworkers.org/2007/11/13/improving-agile-in-product-designing

InfoQ的一篇题为“ 敏捷遭遇实效营销”的新闻指出:敏捷方法不是产品开发中的银弹。当然我们早就知道 没有银弹,但仍然有必要强调一遍,尤其是在这个敏捷方法在中国逐渐开始热门的时候。
有一件事是可以肯定的,即敏捷方法并不能解决业务中的根本性问题,尤其是当业务本身不能决定如何做,或无法决定优先级时,敏捷方法根本帮不上忙。

几乎同时,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的 回复里说的,有了敏捷方法,还要有一套全流程的产品设计方法支持,才可能做出好的产品。这就是我们要去学习和探索的方向。



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1881989


你可能感兴趣的:(产品)