关于原型法，以及敏捷的需求 2010-9-13

前几天在网上瞎逛的时候看了一篇关于原型法的文章，后来觉得很不错，想要去找，当然是找不到了。

不过原型法大致的目的和方式已经很清晰。实际上，在上学期上的SSD4课程中，用户界面中的快速原型法给了我相当大的启发。

首先要明确的一点是，用户关注的焦点大部分情况下是界面。至于安全、健壮等其他后台的内容，用户往往不关心也不需要关心。对于用户的要求不能假设过高，我想这是所有软件工程需要明确的第一点。我想，软件工程的需求之所以成为很多软件团队开发的瓶颈以及很多软件开发返工的主要原因，正式过高的估计了用户，同时过于以自我为中心。敏捷开发的一点要求就是所有队员必须要虚心。我想，这是打通技术人员和用户之间沟通的必经之路。

当然，原型法不仅仅如SSD4中只是一个界面。快速原型是一个原型系统，包括了相当基本，甚至不是正确的功能。原型的主要目的是给用户一个直观的软件呈现，让用户理解程序员眼中的软件，便于给出反馈，让用户能够与程序员更好的交流。

1. 在需求分析的初始阶段，需求人员和用户紧密的配合完成一份最基本的要求。快速分析的关键是要选取核心需求来描述，先放弃一些次要的功能和性能。尽量围绕原型目标，集中力量确定核心需求说明，从而能尽快开始构造原型。
2. 有了初始需求，便可以快速开发一个可运行的系统。忽略一切次要的或者能够引起开发时间过长的功能，取出界面、功能响应等主要涉及到用户体验的元素来进行开发。开发时间控制的非常短，这也要求这必须是一个原型。这个原型既可以是之后进一步开发的基础，也有可能在需求确认之后被抛弃。因此，程序员不必把他做的尽善尽美。
3. 接着，用户和开发人员开始共同讨论这个原型，此时，用户拥有一个切实可感的虚拟系统，可以更轻松的和开发人员确认需求中的细节，来检验初始的需求描述中是否相符以及是否表达出了完整的需求。开发人员也需要向用户解释由于原型的不完善性未能体现出的需求中的部分，从而进一步消除误解，对系统进行改进和增补，甚至推倒重来。

在三个步骤之后，预期将形成一份相对完善的需求文档，此时，开发团队根据新的需求决定是否放弃之前的原型，并开始真正的设计和编码工作。

在这种情况下，仍然是按照需求-分析-编码-测试的传统流程来的。当然，这可能是迭代或增量过程中的一个步骤。

相比之下，前几天研究敏捷的需求分析，与敏捷开发紧密结合的需求分析或者能够更加适合现代互联网程序需求更新快的局面。互联网可以说是软件产品的未来，也是发展最迅速的产业。在互联网背景下，常规软件工程进行两个月开发之后得到产品，可能会发现市场已经发生了变化，软件亟待升级。在这种情况下，传统的计划性的软件开发将被用户不断修改的需求所拖累。

而敏捷天生便是为了解决需求而来。在敏捷的每一次小迭代中（Scrum中称为冲刺），每次迭代的开始都需要确认需求。而敏捷的每一次迭代都是完成一个完整的可运行的系统。这使得敏捷具有原型法的特征。事实上，每一次冲刺之后产生的系统，都是下一次冲刺的原型，用户会在这个原型的基础上进行需求的确认，从而进一步增强了整个开发过程中用户和开发者的交流。敏捷过程中的stakeholder将能够通过不断的沟通来一步步的确认需求，同时保证用户在开发一段时间后，产生的新想法能够兼容到开发中，这个新想法将会在某一次冲刺中实现，最终形成贴合用户需求的系统。