1）快速原型法，可以替代需求 软件工程项目中，经常会遇到这样一种尴尬的局面，我们调研完需求，做完设计，代码也编写的差不多了，这时请客户过来一看，客户却惊奇地发现这根本不是他们想要的东西。 为了让客户更早更快的对将要建成的软件系统，有直观和感性的认识，我们便建立一个系统原型，用于给客户做演示。客户在我们演示和讲解的时候，马上就可以发现问题，而我们甚至可以现场修改原型，直到客户满意为止。 从理论上说，快速原型法确实几乎没有任何问题。但实际情况并非如此。 第一点，也是最重要的一点，快速原型法无法解决需求主线的问题。关于需求主线前文已经讲得很多，而调研需求主线的禁忌中，就特别提到不可以上来就做原型。 说直接点，你是做了某个模块或功能的原型，而且这部分原型也得到了客户的认可，但项目中真的需要这个模块或功能吗？另外更可怕的一点，当你宣告整个项目的原型已经制作完毕，并且全面得到了用户的认可，而那些必须有的需求主线，真的全部包括进来了吗？ 第二点，快速原型法背后还隐含了一个假设，客户就有极高的计算机素养，非常清楚自己需要什么样的系统，他的认可就标志着原型已经合理且完善。但现实中，绝大多数情况下，这种假设是不成立的。 我们知道，客户方的角色实际至少可以分为两个部分：项目发起人与项目负责人。发起人多数是职能部门，而负责人是IT部门。你能指望职能部门的最终使用者，能有多大的概率说清楚自己到底想要什么。 第三点，再好的原型，它的层次感也要弱于建筑行业的沙盘或效果图，这使得原型演示不可能完美的表达软件系统建成后的效果。 以大楼建设为例。我们可以用幻灯片或沙盘的方式，首先展示建筑的外部环境、外观设计。然后再进入到某一层的楼层布局设计图，在进入到该楼层某个房间的布局设计图。这些甚至可以用3D的方法演示出来。再配合讲解，就能够使客户非常清晰全面的了解到整个设计。 我们知道，一个大型软件系统，可能包含几十个大模块、上百个小模块，成百上千的界面，而涉及到按钮、功能键、数据输入和显示等细节甚至多达数万个。这样庞大的软件系统，要去演示它的软件原型，我们就只能在屏幕上，演示一个又一个的界面，根本无法遵行从整体到局部再到细节这样一个流程来展示。 这样的一种情况，相当于在建筑行业中，客户要求你盖一栋商业、办公综合性大楼，而你给客户演示的幻灯片，却只是一大堆的房间、厨房、卫生间、甚至于类似排气扇、开关之类非常细枝末节的东西。又如何让客户提意见，客户又从何提起？只见树木，不见森林，说的就是这个意思。 在快速原型法相关知识普及率如此之高的情况下，软件项目失败率依然居高不下，其最根本原因，就在于此。在笔者看来，只有当需求分析已经细化到具体某个界面的时候，快速原型法的好处才能真正体现出来。而在此之前的仅仅只能用于确定界面布局，以及界面风格。否则将不会对项目有多少帮助。 2）迭代次数越多，越能贴近用户需求 曾经有一次到一个朋友公司去谈事情，到朋友的办公室的时候，恰好有一个项目经理正在汇报项目进度。朋友知道我也是做软件工程管理的，就让项目经理继续汇报。当时项目经理说的有一件事情记忆特别深刻：“现在的原型和设计已经进行到第5次迭代……”。似乎迭代次数越多，就代表项目越能取得成功。 完成一个软件项目，特别是大型的软件项目，总是需要很长的时间，为了避免在项目已经进行到尾声的时候，才发现原来和用户的要求有很大的差别，于是产生了迭代法。 迭代的方式如下，假如这个项目要求6个月交货，我在第一个月就会拿出一个产品来，当然，这样会很不完善，会有很多功能还没有添加进去，bug很多，还不稳定，但客户看了以后，会提出更详细的修改意见，这样就知道自己距离客户的需求有多远。 回家以后，再花一个月，在上个月所作的需求分析、框架设计、代码、测试等等的基础上，进一步改进，又拿出一个更完善的产品来，给客户看，让他们提意见。 就这样，我的产品在功能上、质量上都能够逐渐逼近客户的要求，不会出现我花了大量心血后，直到最后发布之时才发现根本不是客户要的东西的情况。 对比快速原型法和迭代法，就可以发现它们所需要解决的核心问题是一样的，那就是如何应对和适用客户需求在项目实施过程中的变化。实际上快速原型法中就包含了迭代的意思。它的目标是争取在设计、编码开始前，将客户的需求稳定下来。 而迭代法则走得更远，它发现在客户需求变化几乎贯穿了软件工程项目的整个过程，而不仅仅是在需求调研过程之中。于是迭代法就包含设计迭代、代码迭代、测试迭代。 但迭代法的同快速原型法一样，它重点仍然是着眼于如何应付需求的变化上，只是把变化扩展为整个开发过程。也因此，迭代法仍然无法摆脱上述快速原型法中，讲到的只见树木不见森林缺陷。 3）敏捷开发和极限编程，可以应付需求变动 敏捷开发这个词很好很形象。它使我仿佛看见一幅场景：两个人正在做游戏，一个人不停的丢出鸡蛋，而另一个人则敏捷地接下所有的鸡蛋，避免它掉在地上摔碎。 确实，在没有很好的办法将需求主线弄清楚，同时能够较清晰的界定需求范围的情况下，敏捷开发和极限编程中的一些方法，确实可以一定程度上减轻需求变动带来的危害。 但无论是敏捷开发也好，还是极限编程也好，它们都有一个特定的要求：现场客户（On-Site Customer）。敏捷开发对现场客户的要求如下： 1.开发人员需要和用户保持现场的接触； 2.现场的用户要有足够的权限和能力，提供目前建构中的系统相关的信息；能够及时、中肯的做出和需求相关的决策；并决定它们的优先级。 3.现场用户包括：直接用户、他们的经理、高级经理、操作人员、支持人员。 换言之，先无论后面我们采用什么样的方法或组织构架进行设计、编码以及测试，都必须建立在这个基础之上：客户能够准确、清晰、无遗漏的表达出自己的需求，且这些人员包括了所有的直接用户、经理、高级经理、操作人员、支持人员！这样的一个基础，有多大的可能性？别说我们面对的客户千奇百怪，就算是那些计算机企业巨头内部的管理系统，又能够达到多高的满意程度？ 建立在这样一个基础上的软件工程，无论在上面采用多好的技术或构架，显然都不可能确保成功率，看天吃饭依然是软件工程的主旋律。在文章开篇我们就讲到，软件工程的成功，不取决于你到底使用了什么平台，也不在于你是否使用了什么开发工具、使用了什么程序构架。而取决于你是否真正了解了客户的需求。原因就在于此。