看一幅图
我们先看这两组蒙娜丽莎图，代表“瀑布模型”的是上面一组，还是下面一组？
其实答案本身不重要，重要是在这个过程中，我们是否始终问客户，这幅画中哪些部分最重要？
第二组图中，每组画的五个阶段都是画的整个范围，只是完成的程度不一样。假设一个问题：如果原来估算完成这幅画需要5个月，而客户突然要我们2个月就交货，这时候我们只完成到第2幅画的阶段。这样的作品可以交付吗？
第一组图中，整幅画被切分成若干个部分，而每个部分都按照最终交付标准来完成。同样的标准，这组图中的第二幅画可以交付吗？
如果客户说蒙娜丽莎的上半部最重要，那么第二幅画是可以交付的。
这个过程就是迭代开发的过程，这也是瀑布和敏捷开发最大的不同。
做一个游戏
大家回想一下，每天上班出门前：从睁开眼睛那一刻到出门，一共要做多少件事情？
我相信会有很多，从起床、去洗手间、刷牙、洗脸、喝水，梳头、到吃早餐、换衣服、换鞋子，再到出门。整个过程我们需要半小时的时间。如果现在要求10分钟内必须出门，那么我们就要思考哪些事情可以省略掉，而哪些事情必须保留，比如：去洗手间、刷牙、洗脸、换衣服、穿鞋。保留后的就是“最小可用产品” （Minimal Viable Product，MVP)。
总结一下，为什么要定义MVP呢？
首先，开发一个功能所需要的时间与成本总是超出预期的；
其次，需求是需要验证的假设。通过MVP可以快速实验，通过最小成本验证需求假设是否成立；
最后，MVP是从整个业务角度来找出一个既能实现相同业务目标、IT成本又最小的方法来快速启动新业务。
看一次上线
再来举个例子，如果我们要开一家提供网上订餐服务的餐厅，最完美的解决方案是开发一个自助网站，让客户可以自己登录、订餐、支付，然后订单能够进入厨房。制作完成后，通过订单的地址将餐交付给客户。但IT部门要做这样的网站需要3个月的时间，而我们想把这个生意尽快做起来，最好能在半个月以内（很短的交付期限）完成。IT部门的答复是半个月内只能做一个静态的网站，把我们提供的菜式的图片展示出来。我们考虑以后，认为这样也可行，只要把我们的订餐热线电话显示在网站上即可。这样客户可以通过热线来订餐，我们的生意就可以在半个月内运作起来，而IT部门也不再是开业的一个障碍。我们用最短的时间、最小的成本去验证这个商业模式是否可行。这个静态网站就是最小可用产品（MVP）。
这里审视的是整个商业模式，不光是IT功能。对于我们的餐厅而言，更重要的是这样的外送服务模式是否可行、以及菜品是否受欢迎。
这里对我们的启示是：我们应该和业务部门一起通过用户故事地图（设计思维）等方法重新审视整个业务模式如何在期限内运作起来，由此所需要的最小可用产品是什么？我们必须面对的事实是，IT部门开发一个功能所需要的时间和成本往往超过预期。因此我们不应该把业务模式的运行寄望在IT部门把所有原来设想的功能都实现的基础上，尽量使IT部门不要成为业务模式在限定期限内运作起来的瓶颈。
通过打造MVP，让业务模式运作起来，然后再持续改善，不断完善产品。定义了MVP相当于制定了产品的第一个发布版本的范围，我们可以为其余的用户故事制定后续的发布计划。
