针对传统的V模型开发与敏捷开发的优劣势分析，有人说，汽车行业只能采用传统的V模型生命周期的产品开发，IT软件行业采用敏捷迭代的方式，也有人说，现在所有的行业都在谈敏捷开发，应该都是适用的，我们应更全面的从V模型转向敏捷开发。到底是哪一种更有优势呢？
先说我的观点，我认为之所以会出现这样的争论，是没有搞清楚V模型开发与敏捷增量式开发各自的特点，传统的V模型是“广度优先”的方法，V模型的左侧需求定义，系统、组件、零件的设计，而右侧是零件、组件、系统的验证，这样有一个比较严谨的规划与验证活动，但造成开发周期时间长，对需求不断的变更不友好，不能随应市场需求的快速变化。而完全敏捷的增量式产品开发模型是“深度优先”的方法，将产品开发切分为一个小段或区间，通过这种快速的迭代，提升项目的进度和质量，但重构现有设计可能会需要太多的工作量，适用于软件行业。随着市场不断的变化、产品的生命周期不断减少、产品质量要求日益提高、而产品开发成本也在不断下降，传统的机械、电子产品都会向IT软件学习，从“广度优化”的V模型产品开发向以“深度优先”的敏捷增量式开发转变。
汽车行业的V模型开发
软件行业的V模型开发
要理解什么是敏捷增量式开发，我们来看看一个案例。话说早些年，客户是国内一家著名的电视台，需求是一款能支持现场打分、场外短信支持、候选人得票情况的可视化显示解决方案，总之，是一个功能多，交互复杂的系统。当年的选秀节目是一个新趋势，所以开发人员也不知道客户想要什么样的东西，但电视台自己也不知道具体产品长什么样，总之大概的需求是“要酷、要震撼，要能调动观众的积极性····等等，需求模糊，说不清楚。”
按常规的开发流程如下：需求分析、设计、编码、测试、交付等，可以想像在该流程下，核心的就是需求分析，一旦需求分析出现大的偏差，之后的所做的所有东西再好，都是徒劳，最后的交付根本不是用户想要的。
总之客户的需求说也说不清楚，最后的结果是，参考电视台的说法和我们自己的猜想，整了一个“需求分析”出来，然后将需求描述发给电视台，也不知道对方到底有没有认真看过，反正最后的回复是：就是它，尽快干出来吧。
接下来，我们加班了3个月，欢天喜地给电视台看，本来大家的期望是掌声和赞美，但没有
想到，客户看了之后非常失望，说根本就不是他们想要的东西，我们和客户争辩说，需求分析你们也认可的，怎么可能不是你们想要的东西呢？结果客户也很委屈，我们是看过“需求分析”了，但这肯定不是我们想要的东西。
后面我们才明白，传统的V模型开发，你必须对你将要开发的产品有一个非常深厚的理解与掌握，而且随着项目进展，竞争对手的出现，需求也可能随时变化，这种自上而下的开发方式，无法响应客户需求不断的变化。
产品开发的工作任务是有不同的先后顺序和程序的，传统汽车工厂采用的是V型瀑布式产品开发模型。V模型的左侧的活动是系统需求分析、架构设计、产品开发等，右侧的活动是系统、组件、零件及材料的验证。
V模型是“广度优先”的方法，因为假设每个工作都能在该点上完整的、精确的且正确的实施，通常在产品设计完成的每个阶段，都会输出设计文档，唯一验证的手段是“语句”评审，况且中文字博大精深，一句话有不同的描述，好像含义也是差不多的，这样的评审称为“语句”评审，是往往是最薄弱的方法。这意味着经过批准和签字评审而发布的设计文档会存在很多缺陷没有被发现。后续的变更自然很难，因为它们的批准是麻烦的、昂贵的且是耗时
的。由于创建规范和对其验证时间有很长的延迟，这样可能验证的结果达到预期的要求，可能带来变更。
由于变更批准的工作是规划外的工作，因此估计实际上接近发布产品程度就变得很难。在以V模型生命周期做规划时，假设对项目的了解具有无限的深度、广度和稳定性。打个比方，通过漫长的设计与评审，然后制造原型样件进行验证，而整个原型样件的测试都花了3个月，最后验证试验失败，需要变更，谁都接受不了或难以接受，所以V模型对变更非常不友好。
但实际产品规划时不仅有未知因素，即使是已知道的事情也将会发生变化，V模型生命周期对变更需求、变化、技术和人员配备相当的抗拒。也就是说，使用V模型必须对产品做深入的思考，同时不随应市场快速变化的需求。
对前面的V模型决然不同是另一个极端，完全敏捷的增量式产品开发模型，在增量式的观点中，产品开发可以切分为一个小段或区间，称为迭代，这种方法的好处是，可以增量式的快速进行验证与确认设计输出，从而提高开发质量和效率。
敏捷增量式开发在一个相对小的功能部分通过所有活动，包括所有的验证和确认活动，产生一个产品版本，然后再增量式地添加下一个功能部分。这是“深度优先”的模式。它每一个功能都是从客户的需求出发，进行设计、然后验证与确认的过程。这种小步快跑的模式，就叫迭代。
敏捷增量式开发有以下假设：
1、一次的迭代必须是独立的功能，并能完整地进行验证和确认，以满足用户的一个独立的功能性需求。这个假设比较容易满足，只需要将产品的功能切分为足够小的单元，并通过一系列的设计、验证、确认活动，来满足客户的需求。
2、重构现有设计和实现纳入新功能的必要工作量要比实现新的功能性少得多。在软件开发中，采用敏捷增量式的迭代方法，是因为重构和纳入新功能更加容易。所以对于软件行业，敏捷开发的第二个假设条件很是容易满足的。但是对于硬件开发，由于物理现实世界的约束条件，在创建物理部件时需要较长的准备期，你可以随便说晚上软件升级一下，但模具回厂后，你说迭代升级一下是不现实的。因此这对于机械、电子产品适用性比较差。比如你设计一个电源系统，供应汽车收音机的电源需求，但后来却发现还要给其它系统供电，采用纯粹的敏捷增量式开发不适用于所有的产品开发，因为这里重构电源的开发可能会需要太多的工作。打个比方，你设计的电源系统为12V，后续电源需求给其它系统，要改为36V，如果采用迭代开发，将每个系统的功能分析开发，重构电源的开发时间与成本都非常高。
发布评论