先说我的观点，我认为之所以会出现这样的争论，是没有搞清楚V模型开发与敏捷增量式开发各自的特点，传统的V模型是“广度优先”的方法，V模型的左侧需求定义，系统、组件、零件的设计，而右侧是零件、组件、系统的验证，这样有一个比较严谨的规划与验证活动，但造成开发周期时间长，对需求不断的变更不友好，不能随应市场需求的快速变化。而完全敏捷的增量式产品开发模型是“深度优先”的方法，将产品开发切分为一个小段或区间，通过这种快速的迭代，提升项目的进度和质量，但重构现有设计可能会需要太多的工作量，适用于软件行业。随着市场不断的变化、产品的生命周期不断减少、产品质量要求日益提高、而产品开发成本也在不断下降，传统的机械、电子产品都会向IT软件学习，从“广度优化”的V模型产品开发向以“深度优先”的敏捷增量式开发转变。
汽车行业的V模型开发
软件行业的V模型开发
要理解什么是敏捷增量式开发，我们来看看一个案例。话说早些年，客户是国内一家著名的电视台，需求是一款能支持现场打分、场外短信支持、候选人得票情况的可视化显示解决方案，总之，是一个功能多，交互复杂的系统。当年的选秀节目是一个新趋势，所以开发人员也不知道客户想要什么样的东西，但电视台自己也不知道具体产品长什么样，总之大概的需求是“要酷、要震撼，要能调动观众的积极性····等等，需求模糊，说不清楚。”
按常规的开发流程如下：需求分析、设计、编码、测试、交付等，可以想像在该流程下，核心的就是需求分析，一旦需求分析出现大的偏差，之后的所做的所有东西再好，都是徒劳，最后的交付根本不是用户想要的。
总之客户的需求说也说不清楚，最后的结果是，参考电视台的说法和我们自己的猜想，整了一个“需求分析”出来，然后将需求描述发给电视台，也不知道对方到底有没有认真看过，反正最后的回复是：就是它，尽快干出来吧。
接下来，我们加班了3个月，欢天喜地给电视台看，本来大家的期望是掌声和赞美，但没有想到，客户看了之后非常失望，说根本就不是他们想要的东西，我们和客户争辩说，需求分析你们也认可的，怎么可能不是你们想要的东西呢？结果客户也很委屈，我们是看过“需求分析”了，但这肯定不是我们想要的东西。
后面我们才明白，传统的V模型开发，你必须对你将要开发的产品有一个非常深厚的理解与掌握，而且随着项目进展，竞争对手的出现，需求也可能随时变化，这种自上而下的开发方式，无法响应客户需求不断的变化。
产品开发的工作任务是有不同的先后顺序和程序的，传统汽车工厂采用的是V型瀑布式产品开发模型。V模型的左侧的活动是系统需求分析、架构设计、产品开发等，右侧的活动是系统、组件、零件及材料的验证。
V模型是“广度优先”的方法，因为假设每个工作都能在该点上完整的、精确的且正确的实施，通常在产品设计完成的每个阶段，都会输出设计文档，唯一验证的手段是“语句”评审，况且中文字博大精深，一句话有不同的描述，好像含义也是差不多的，这样的评审称为“语句”评审，是往往是最薄弱的方法。这意味着经过批准和签字评审而发布的设计文档会存在很多缺陷没有被发现。后续的变更自然很难，因为它们的批准是麻烦的、昂贵的且是耗时的。由于创建规范和对其验证时间有很长的延迟，这样可能验证的结果达到预期的要求，可能带来变更。
由于变更批准的工作是规划外的工作，因此估计实际上接近发布产品程度就变得很难。在以V模型生命周期做规划时，假设对项目的了解具有无限的深度、广度和稳定性。打个比方，通过漫长的设计与评审，然后制造原型样件进行验证，而整个原型样件的测试都花了3个月，最后验证试验失败，需要变更，谁都接受不了或难以接受，所以V模型对变更非常不友好。
但实际产品规划时不仅有未知因素，即使是已知道的事情也将会发生变化，V模型生命周期对变更需求、变化、技术和人员配备相当的抗拒。也就是说，使用V模型必须对产品做深入的思考，同时不随应市场快速变化的需求。
对前面的V模型决然不同是另一个极端，完全敏捷的增量式产品开发模型，在增量式的观点中，产品开发可以切分为一个小段或区间，称为迭代，这种方法的好处是，可以增量式的快速进行验证与确认设计输出，从而提高开发质量和效率。
敏捷增量式开发在一个相对小的功能部分通过所有活动，包括所有的验证和确认活动，产生一个产品版本，然后再增量式地添加下一个功能部分。这是“深度优先”的模式。它每一个功能都是从客户的需求出发，进行设计、然后验证与确认的过程。这种小步快跑的模式，就叫迭代。
敏捷增量式开发有以下假设：1、一次的迭代必须是独立的功能，并能完整地进行验证和确认，以满足用户的一个独立的功能性需求。这个假设比较容易满足，只需要将产品的功能切分为足够小的单元，并通过一系列的设计、验证、确认活动，来满足客户的需求。
2、重构现有设计和实现纳入新功能的必要工作量要比实现新的功能性少得多。在软件开发中，采用敏捷增量式的迭代方法，是因为重构和纳入新功能更加容易。所以对于软件行业，敏捷开发的第二个假设条件很是容易满足的。但是对于硬件开发，由于物理现实世界的约束条件，在创建物理部件时需要较长的准备期，你可以随便说晚上软件升级一下，但模具回厂后，你说迭代升级一下是不现实的。因此这对于机械、电子产品适用性比较差。比如你设计一个电源系统，供应汽车收音机的电源需求，但后来却发现还要给其它系统供电，采用纯粹的敏捷增量式开发不适用于所有的产品开发，因为这里重构电源的开发可能会需要太多的工作。打个比方，你设计的电源系统为12V，后续电源需求给其它系统，要改为36V，如果采用迭代开发，将每个系统的功能分析开发，重构电源的开发时间与成本都非常高。
几乎所有的敏捷都是关于IT软件的开发，很少关注机械、电子方面的产品开发。但我们还是尽力将敏捷的核心思想引入到硬件产品开发中。敏捷方法就是使用客观证据，指导如何做好工作并针对不同情形和变化的需求进行适应和响应。而传统方法将推迟产品的验证与确认，至少要在完成这些工作产品时进行验证，而且往往很晚了。
我们将敏捷方法当作保健学，如果我们认为刷牙是一个好方法，那我们花半年的时间进行策划，然后在每年的12月31日进行彻底清洗一下，这与传统项目到达最后才进行综合验证和测试类似。实际到了年底，我们大概率不会得到期望的好产品，我们将以高成本的方式处理缺陷，如蛀牙。而敏捷方法是我们每天早晚清洁牙齿，只要每次吃完饭就刷一次牙，就像增量式不断的迭代，以最大程度的避免缺陷和提高效率。也就是说，敏捷方法在整个产品开发过程中都执行质量保证活动，而不是在开发完成后进行验证与确认。
我们再打个比方，某作家准备写一本书，那我们花大半年的时间进行策划，然后花大半年的时间进行写作，到了年底书本发售，是否能得到一本好书，大概念是令大家失望的。这与传统项目开发一样，只有最后才知道是不是一件好产品。而敏捷开发是将一本书，先写出大纲，然后列出每一章的内容，接着写完一个章节，不急于写下一个章节，将前面已完成的内容，发到个人网站或公公众号，看读者是否感兴趣，是否通过点击增加纯推荐值。如果大家感兴趣，我们再写下一章节，如果某章节没有达到客户的期望值，也可以立即改变言题。每一章节的内容都得到客户的验证，相当于敏捷开发的快速迭代与验证，如果这样操作下去，我们大概念可以想像年底的书本发售，是能满足预期期望的。
曾经大导演张艺谋说，一部电影拍到一半或者还没到一半，导演就知道该片是不是烂片了，有人肯定要问，明知道是烂片，为什么还要继续往下拍呢？没有办法啊，资本加持，前期的投入巨大，大家都看着，是没有办法停止的。大家想想，是不是觉得大导演也挺可怜的，明知道是个烂片，明知道放映时会招人讨伐，但没有办法停止。这个大导演，在企业里就是项目经理或开发总监，明知道产品上市有问题，或不可能得到客户的需求，也不得不推出上线。
敏捷开发就是螺旋式开发，基本概念就是将产品功能切成为独立的、可以验证的小功能。这些通常是4-6周的时间，一些软件开发中会降到1-2周的时间。通过这种快速的迭代，提升项目的进度和质量。可以按照以下步骤来完成：1、产品开发任务必须可线性分拆到独立验证的部件中，也就是说，如果某一工作任务完成后，经过验证，后续的重构工作不会很多或只需少量的工作。这一点非常重要，这也是很多专家认为敏捷开发不适用硬件开发最重要的主张，因为硬件开发在迭代后重构时间过长。
2、将工作分解到5个或更多的迭代，理想的情况下，每次迭代时间长度为2-4周。
3、每次迭代结束时验证产品的质量，并修复所有的主要缺陷。因为需求是易变的，因此不像传统的V模型开发那样，一开始就制定整个产品的详细开发计划。而是提倡小步快跑的方式来开发整个产品功能，通过一个小计划接着一个小计划，通过反复迭代，最终实现产品的自我完善。能够看出，这种短节奏、快调整的开发模式，对于传统开发模型来讲，最大的好处是灵活多变，反应敏捷，任何时候，只要市场有变化，就马上调整下一步的开发计划，甚至是彻底放弃，及时止损。
美国的电视剧是边拍边播的，非常重视收视率，一部收视率低下的电视剧是无法生存的，只要吸引不了观众的注意力，那么不管该剧的情节进行到何处，电视台都毫不留情地腰斩。每周播一集，边拍边播，根据该季的播出效果来决定是否该继续拍摄下一季。这一点很像敏捷开发模式，每周一集的播出，就相当于每周的客户验证，有时还会根据观众的意愿更改剧情，拥有极强的灵活性，随时响应客户需求的变化，如果不行马上修改，如果修改不行，彻底放弃止损。
国产电视剧从前期筹备、拍摄、后期宣传都由制作公司承担，是否能盈利，要看最终给电视台是否能卖个好价钱，电视台承受低风险但获得高收入，电视剧只有全部制作完成，并成功在电视台上映，才算成功，但收视率得看概率了。这一点很像传递的V模型开发，不能随时响应客户需求的变化，所以制作方为规避风险，也不敢创新，往往会迎合观众愿意的都市剧、古装宫斗剧、青春校园等。
正如我的偶像雷布斯，对小米的七字口诀：专注、口碑、快，这七字口诀也反映出他们的开发模式绝对是敏捷开发，早期雷军每周迭代，每周三发升级预告，周四内测，周五上线，如果有时候周五发不出去，那只能周末加班了。
大家也不要觉得搞敏捷开发很厉害，其实我的理解正是因为团队不够牛逼，没法对开发作出长远、详细的规划，或者无法掌握客户的需求变化，所以才退而求其次，选择快速迭代的方法。我们的伟人曾说过，如果无法确保一次成功的话，我们可以摸着石头过河，因为我们不会游泳，不会搭桥，不知河底是深是浅，才逼出我们整了一套方法，这套方法可以叫“模石头小过河”模式。
网上有位朋友这样说明传统开发与敏捷开发的区别，把传统的开发方式比喻成普通火炮，而把敏捷开发比喻成导弹，两种武器打击目标过程就能形象的说明两种模式的区别，火炮打击目标，要想打得准，则要寄托一开始够准，而对目标运动轨迹估计得够准，一旦炮弹发射出去，就无法对速度、方向进行控制了。任何瞄准偏差，没有预料到的目标移动轨迹变化，甚至风向的变化都会导致炮弹打偏，这就是传统开发的特点，一开始就要做详细的需求分析及规划，你得对产品有足够的了解，而且对需求变化不友好。
而导弹就不一样了，只要设定好目标定位，并不需要一开始就精确瞄准，导弹发射出去后，会持续的收集自己的位置、方向、速度并根据目标的方位不断的调整，最终能够长距离精确地命中目标。这就是敏捷增量式开发的特点，摸着石头小步过河的模式，不需要一开始就有详细的需求分析及规划，能顺应市场需求的变化。
综上所述，相信无论是软件开发，还是硬件开发，在产品生命周期越来越短的市场环境下，通过敏捷增量式的开发方式，将工作分解到可以独立验证的部件或功能，通过2-4周快速迭代节拍，确保产品的开发进度与质量。
