敏捷与产品开发

InfoQ 敏捷社区最近发布了一篇新闻《敏捷遭遇实效营销》 ，其中提到科技领域的产品管理方法论——实效营销 ，并指出实效营销“不但展现了敏捷方法的价值观和原则可以成功地应用在业务方面，而且更重要的是，某种意义上，它还试图说明，在什么情况下敏捷开发实践不 起作用。”虽然文中没有明确说明，不过我们可以从中得出结论：相对于定制项目来讲，敏捷方法论对于新产品的研发，并不能起到特别大的推动作用。

对于这个问题，王晓明（ThoughtWorks 业务分析师，拥有采用敏捷方法开发和管理大型政府和企业应用开发项目的丰富经验）在自己的一篇 blog 中，提到了为什么会这样的原因：

在项目开发与产品开发之间区别是：项目有明确的外部用户和客户目标，而产品则不是。敏捷在面对不明确的需求和需求提炼方面有明显 的优势。在实施敏捷时，我们不能容忍存在基于假设的、不确定的业务和需求分析。我们要知道用户与客户真正需要的东西，他们的基本需求是什么，他们希望拥有 什么或喜欢拥有什么。……相对项目而已，产品开发有两个主要的不同点。首先，对于产品来说，同时存在目标客户与潜在客户。即使是在理想状况下，假定我们可以与所有的目标客户 面对面接触（实际状况下，这基本上不可能发生），我们仍然不能得到他们的全部需求。……第二个原因是：从市场角度来讲，一个产品必须要很有创意。你可以想 象：一个没有新想法的产品没有顾客会购买的，除非有很大的价格优势。……

针对此问题，胡凯认为：

……产品有产品的难点 。 - 需求：既然是产品，大多数的情况下是有很多同类产品不具备的功能，否则，很难在饱和的市场中分得一杯羹 (开拓市场更得需要一些新的思路和功能)，这样产品中的很多功能是有前瞻性的­，用户也许并没有这样需求或者还没有意识到自己有这样的需求，BA 也许很难作出需求分析。

• 简单：产品的命运很多时候再初一登陆市场的时候就确定了，用户试用了你的产品后如果印象不佳，也许以后都不会再使用你的任何产品。这样 使得产品很难使用发布 -­反馈 - 改进的方式，也是由于这样的原因很多产品会有开源的版本，希望依赖社区的力量在商业版本发布前尽可能多的获得反馈，设计出 用户需要的产品。
• 改进 - 反馈：如果发现某些功能多余，或者进行大规模的调整的时候都必须特别的注意，因为在这个世界的某个角落，还有人使用你的产品 N 年前的版本，你的升级也许会让这些人无法工作，但是这些用户很可能不会再你所发布的若干个 RC 版本向你提出任何反馈，或许就在发布的庆功宴进行的同时， 很多愤怒的 EMail­出现在你公司的邮箱中。

不过，王晓明仍然认为敏捷还是适于软件产品开发的，不过要有选择地实施敏捷实践：

……极限编程、结对编程、scrum 和 TDD 都是好的实践，因为它们不依赖需求分析的结果。

最后，王晓明告诫大家：

要牢记在心，产品的灵魂核心在于创意和差异化。有时，我们必须抛弃循规蹈矩的做法，而且要冒很高的风险。这时一定要高度关注风险管理。

InfoQ 中文站在四个月之前有一篇熊节的原创新闻：《敏捷的核心：消除浪费，走向精益》。研发新产品时，如果强要在创意收集和设计阶段使用敏捷方法和实践，必然会造成浪费。那么我们这些“软件人”是不是就要脱离开产品设计阶段呢？李默根据自己在实际工作中的实践，在 “敏捷中国”Google 网上论坛讨论贴中开宗明义地指明：

敏捷过程中的 BA 角色应当更加多的参与甚至融入到 marketing 的团队中，从一开始的 Marketing segment 就开始。

熊节更是在自己的 blog 里面提出：

有了敏捷方法，还要有一套全流程的产品设计方法支持，才可能做出好的产品。这就是我们要去学习和探索的方向。

归根结底，正像 alexgreenbar 在 Javaeye 一篇帖子中提到的，敏捷：

……不是对每种类型的软件开发都适合，它自有其适应的合适领域……

这无疑是正确的。不过究竟哪些领域不适合采用敏捷，在这些领域应该用什么技术来弥补敏捷的不足，请问您有何高见？

作者简介：郑柯，目前任职《程序员》杂志社高级编辑，有志于在中国的软件开发业界推广 Agile 的理念和方法论，笃信以人为本，关注 Ruby，关注敏捷，关注人。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com ，加入 InfoQ 中文站用户讨论组，请点击 ICUG，InfoQ China User Group 。