产品研发中的敏捷:不足与方向
来源:互联网 发布:李孝利人品知乎 编辑:程序博客网 时间:2024/04/30 12:30
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的 回复里说的,有了敏捷方法,还要有一套全流程的产品设计方法支持,才可能做出好的产品。这就是我们要去学习和探索的方向。
- 产品研发中的敏捷:不足与方向
- 产品研发中的敏捷:不足与方向
- 谈保险项目组产品研发方向
- QClub:敏捷在互联网时代产品研发中的实践(12.27 深圳)
- 研发与产品管理
- 研发流程中的产品测试
- 软件产品应用与产品研发
- 敏捷开发产品管理系列之四:新产品研发
- 敏捷研发
- 研发管理中的产品测试管理
- 产品研发的发展与趋势
- android产品研发与用户需求、体验
- 产品研发
- IT研发核心课程系列——移动互联网产品团队的敏捷开发之路
- 中国新药研发方向与国外存在较大差异
- 产品不足运营补
- 腾讯研发项目总监:互联网产品开发中的“快”字诀
- 腾讯研发项目总监:互联网产品开发中的“快”字诀
- 入门不简单
- CSDN社区风雨七年路-访CSDN技术掌门人曾登高
- vi 下多文件编辑的方法
- 强悍的神州泰岳
- 周鸿祎的真经
- 产品研发中的敏捷:不足与方向
- 虚拟货币经济体的技术问题和非技术问题
- science and history of dreams
- 自组织的网游金融体系
- dbdao
- 天地不仁,通货在膨胀
- 从游戏看货币
- 入门ASP.NET中的三层结构
- IT职业教育(12)诚信素质教育重在身教