模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
新闻
敏捷遭遇实效营销
作者 Kurt Christensen 译者 乔梁 发布于 2007年11月11日 下午8时37分
实效营销是科技领域的一种产品管理方法论，和那些敏捷软件开发方法相似，它追求价值与原则。所以，当实效营销者遇到了敏捷开发者，会发生什么呢？最近，Stacey Weber在一篇文章中写道：“文化间的啮合通常是不完美的”。
“严苛”一词是很多公司应用敏捷开发之经验的准确描述，这种方法等于是向快速变化的需求屈服。实际上，我相信正是因为工程师们要处理那些来自执行经理和产品经理的不断变动、又自相矛盾的需求变化，所以产生了敏捷方法。这些工程师与无法决定需求优先级的执行经理一同工作，还有那个忙于想需求而不做市场调研了解真正需求的产品经理……对于工程师来说，敏捷好象就是他们要找的答案，因为他们的团队只关注很少的需求就行啦。他们基本上可以忽略执行经理和产品经理……几个星期后的任何需求变化都可以不管。
先把错误的立论前提先放一边，有一件事是可以肯定的，即敏捷方法并不能解决业务中的根本性问题，尤其是当业务本身不能决定如何做，或无法决定优先级时，敏捷方法根本帮不上忙。Barbara Nelson和Stacey Mentzel在一篇名为《极限项目管理》文章中详细阐述了这一问题。
如果敏捷方法本身可以解决“构建那些大家想要的产品”这一问题的话，那我们就不用写这篇文章了。我们就说“用敏捷吧！”可是，我们一次又一次地听到敏捷方法可以很快交付成果，但如果没有计划和全面蓝图，那所交付的东西（让我们先叫它用户故事吧）可能无法帮助我们卖出更多的软件。
当认识到敏捷方法的这一缺点以后，他们做出下面的反应，即提倡“敏捷瀑布方法”。这一方法实际上是较为强调长期计划的敏捷软件开发方法。一方面，这好象合理且必要的，因为可以让业务人员能够制定长期计划和承诺来销售产品，“有助于创造人们想买的产品”——这是实效营销的口号。然而，业务人员如果过分强调长期计划的话，就不能根据增量开发并实际运行的软件提供的反馈，及时地进行适当调整。毕竟，做产品应该是帮助业务人员更好地理解做什么样的产品，怎么做更好。有点讽刺意味的是，实效营销的应用领域是技术硬件和软件，而真正的技术革新不仅仅是要听市场的呼声；它还要展现市场需要而尚不自知的东西。单凭对营销模拟客户的调查可能发明不出iPhone。
然而，实效营销应该还是敏捷方法的倡导者，因为它不但展现了敏捷方法的价值观和原则可以成功地应用在业务方面，而且更重要的是，某种意义上，它还试图说明，在什么情况下敏捷开发实践不起作用。这是为什么呢？我们能做些什么呢？
英文原文链接：Agile Meets Pragmatic Marketing
敏捷——毫无疑问——不适合产品研发
发表人
Jeff Xiong
发表于
2007年11月12日 上午1时21分
Re: 敏捷——毫无疑问——不适合产品研发
发表人
乔 梁
发表于
2007年11月12日 上午8时51分
Re: 敏捷——毫无疑问——不适合产品研发
发表人
Mo Li
发表于
2007年11月12日 下午9时24分
Re: 敏捷——毫无疑问——不适合产品研发
发表人
凉粉 小刀
发表于
2007年11月12日 下午11时12分
产品和项目的要求的确不同
发表人
cao yunfei
发表于
2007年11月13日 上午12时50分
Re: 产品和项目的要求的确不同
发表人
Xiaogang Guo
发表于
2007年11月13日 上午8时7分
-
或者说得更准确些，对于产品研发，只有敏捷是不足够的。敏捷能做出你想要的，但没办法保证做出好的或者正确的或者受欢迎的。而且作为从内部IT项目衍生而来的敏捷方法，它本身有一种趋势：把功能做到能用而非完美。对于内部IT项目，这很好，两个能用的功能往往能提供比一个完美的功能多得多的价值；但对于面向公共用户的产品，你麻烦了，因为不完美的功能很可能根本就没人用。
交互设计是改进的办法之一。但很多敏捷的组织对此认识并不充分，他们只是在项目进行中让交互设计师来做一次评估和设计。这是不足够的，就好像在软件项目的交付之前才进行QA工作是不足够的一样。质量来自整个流程，同样好的交互设计也来自整个流程。有了敏捷方法，还要有一套全流程的产品设计方法支持，才可能做出好的产品。 -
同意。
客户定制项目与产品项目有着不同的出发点。客户定制项目需求相对实际，而产品规划要有前瞻性。
在软件开发过程中，使用TDD、持续集成等开发实践是有意义的。但在敏捷方法论中的需求决定论用于产品开发似乎不太有效。比如，客户还没有意识到他真正需要什么的时候，开发人员就不知道该干什么了。
在Xiaoming的blog中也提及相关的话题。 -
从实践上讲，个人认为，敏捷过程中的BA角色应当更加多的参与甚至融入到marketing的团队中。从一开始的Marketing segment就开始。事实上，市场划分实践和交互设计中的persona方法有很多相似之处，很大程度上可以融合到一起。
而从逻辑上说，这样的实践并不能保证市场划分的正确或产品定位的准确。市场调查研究和市场策略依然是一个产品最重要的一环。
但这并不是说是敏捷开发实践不起作用，而是因为这是另外的一门学科，本来就不是开发实践应该在的地方。 -
不知道该说些啥好，敬仰一下楼上的三位吧……
-
项目，功能完成就可以交付用户使用了。如果有什么问题，接着修改，再交付。客户也欢迎这样的方式。但是，做产品是完全不同的。如果我们开发出不完美的产品交付给消费者，消费者一旦不满意是没有耐心等着升级的，他们最直接的反应是：删除这个垃圾软件！
-
产品不一定就要交给消费者啊，也是可以“有什么问题，接着修改，再交付”的。办法比如focus froup、不要脸地老是beta/CTP/体验版/泄露版……各有各的招。
6 条回复
关注此讨论 回复