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