用“最小且有市场价值”原则指导产品/项目规划

    在“Software by Numbers – Low Risk, High Return Development书中,Mark Denne Jane Cleland-Huang 提出了一种新的增量软件开发思路:将项目分解成最小有市场价值功能特性(Minimum Marketable FeatureMMF)集。每个小的子集都能实现独立的客户价值,依据这些价值,我们可以找出性价比最好的针对MMF 的开发次序,最大限度地降低我们投入的风险。


一本提了个好概念的书

MMF中的两个M 是关键。第一个M 的意思是“最小”(minimum),因为功能变得更小的话,就没有任何市场价值了。它提醒我们用最小的代价、最快的速度实现能给客户带来价值的功能。不要忘了80%的产品价值是由20% 的功能实现的。在做每一个版本计划时,我们要选择能给客户带来最大价值的最小需求子集。

    第二个Mmarketable)提醒我们,发布的每一个功能都要给客户带来价值。每一个MMF都是产品的一部分,用户会使用或者购买这个功能。

MMF不等同于Scrum 和极限编程中的用户故事,MMF 比用户故事大,往往是多个相关的用户故事构成一个MMF。每完成一个MMF,就可以发布一个新的版本。当然,优先级比较低的MMF可以用一句话的用户故事来描述。

这里我们用一个简单的例子来解释MMF。假设开发团队要为某航空公司开发一个网上服务网站,自然网上订票是一个很重要的功能,在实现这个功能时,团队需要考虑支持多种不同的付款方式。什么是最小有价值的需求子集呢?使用某银行的某个信用卡完成网上订票就是这样一个子集。这个子集会包含下列一些功能:

   查询航班信息;

   选择提交预定航班;

   提交某银行的信用卡信息;

   处理信用卡支付;

   确认航班及付款信息;

   通知用户预定是否成功。

这是一个最小且有市场价值的需求子集,一方面它对乘客及航空公司来讲都有独立的价值,有了这个功能航空公司的服务网站就可以发布了。另一方面它也是个最小子集,因为如果拿掉任何一个需求,对乘客和航空公司就没有完整价值了。例如,如果只能处理信用卡而没有实现其他功能,那么对用户来讲是没有价值的。

请注意,找到最小功能集并不是我们的目的,最小是相对的,它不会能满足所有可能的用户。现实中,不是每一个客户都会对你的所谓最小功能集表示出很大兴趣的,很可能只有小部分特别的用户对它表示关注,因为它会让他们对产品的愿景充满期待。通过MMF,你是在推销产品愿景,最小功能集是给有远见的客户而不是给所有人的。

MMF主要目的有两个:

– 减少工程人员的时间浪费;

– 尽快让软件产品在有眼光的客户手中用起来。

下图展示了项目和MMF 的关系。

 

 项目和MMF的关系


从上图可以看出,MMF 和发布版本不一样,MMF是提供业务价值的功能集合,而版本则是实现客户需求的进度。

Scrum增量开发的关键是识别出MMF,根据它们的价值罗列出开发优先级。理论上讲,只要开发出一个MMF,你就可以发布软件产品并开始看到产品带来的价值。版本计划应该围绕识别出的MMF,同时兼顾技术实现的相关依赖关系进行。

    MMF 方法不是专门为敏捷提出的,但我认为它为如何进行敏捷中的版本计划提供了一个有效的实践。

摘自 《知行合一: 实现价值驱动的敏捷和精益开发》

(点击图片阅读原文)


京东网站:http://item.jd.com/12204885.html


三尺讲桌就在这小小二维码,长按二维码“识别”关注   

用“最小且有市场价值”原则指导产品/项目规划》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/242.html