快速迭代与原型开发

快速迭代与原型开发

l 有了快速迭代之后，是否还需要原型开发？

原型开发的意义在于，我们能够以一种快速简便的方式，在最短的时间内让客户看到系统的雏形。

从这一点看来，原型开发其实也是快速开发的一种实践，它与快速迭代的目的是一致的。

 

l 那么如果有了短时间的快速迭代（通常是半个月，甚至一周），我们还需要做系统原型吗？

如果某一个模块的业务极其复杂，不能在短时间（超过一次正常迭代的时间）内完成粗胚，那么我还是建议先做原型。

现在我们得到了做原型的条件：是否做原型的关键是模块的业务是否复杂。

 

l 那么如何判断这一个模块的业务是复杂的？

通常一个业务复杂的模块，要么它的界面极复杂，要么是流程非常长，甚至两者兼而有之。

对于有经验的系统分析师来说，某些领域已经多次接触（以前就有做过类似的系统），所以对新人来说是复杂的模块，对他来说就是简单的。这种情况下，系统原型也不需要做了，因为以前的系统就是最好的原型。

现在我们得到了对原型条件的修正：如果类似的业务在以前的系统做过，那么就不需要做原型设计了。

 

l 接下来我们讨论完全陌生的领域是否需要做原型。

即使你认为你已经完全掌握了这一模块的需求，并且已经设计了完善的领域模型，但我认为还是要做原型。

为什么呢？

因为客户（甚至是领域专家）只熟悉自身的业务，对计算机系统是完全陌生的；而我们的软件工程师正好相反，我们对计算机系统极熟悉，对领域业务完全陌生。因此，当软件工程师与领域专家沟通时，一定会产生信息失真的情况。

敏捷开发也有类似的假设条件：客户需求永远无法一次性全面调研清楚。

例如领域专家认为显而易见（在他们的领域中是基础中的基础）的东西，根本不需要讲解，却不料这些信息却是极为关键的；或者领域专家认为某些概念是浅显的，不需要过多解释，而软件工程师也认为自己明白了，却不料这些概念（术语）虽然是日常生活中的常见词语，但它们却有着截然不同的业务含义。

类似的情况屡见不鲜，它们都会带来信息失真的问题。更糟糕的是，我们根本无法避免这些问题的发生——有经验的系统分析师可以减少这些问题，但不能完全避免这些问题。

所以经常会发生这种情况：我们辛辛苦苦做完了一个模块（通常要花半个月甚至更长时间），拿给客户看的时候，客户却惊奇地发现这根本不是他们想要的东西。

原型能够提早发现这种情况。通常一个模块的原型只需要一两天时间就可以完成，给客户做演示的时候，客户马上可以发现问题，我们可以现场修改原型，直至客户满意为止。

这就是为什么需要对陌生领域做原型的原因。

 

l 原型开发的优点和缺点

我们发现用一个“真实的系统”（原型）和客户讨论需求是一件愉快的事：对客户来说，原型能够让他们对陌生的软件系统有一个直观的认识，进而指出其中的谬误；而对软件工程师来说，原型最接近客户的真实需求，我们可以最大程度地符合客户的意图。

到此为止，我们发现快速迭代与原型开发并不冲突，因为快速迭代与原型开发都是认为：

客户的需求是不断变动的，而且这种变动是在开发过程中出现的，甚至是取得阶段性成果之后出现的。这种变动是软件开发中不可避免的。为了最小程度地减轻需求变动带来的重复劳动，我们需要不断地贴近客户，让每一步都在客户的观察下前进。

简而言之，原型开发也一种迭代开发，只是它的迭代成本更低，迭代的速度更快。

但是原型也有它的缺点：原型只是系统的mock，也许原型中意图做到的东西，在开发时才发现根本做不到——这有技术上的原因、硬件上的原因、甚至是工期上的原因。

不过这个缺点这不算大问题，我们可以再次与客户沟通，用另外的方式去实现：购买第三方组件、升级硬件、甚至削减功能。相比原型带来的效益，这个缺点不算什么，而且即使没有原型，这样的问题也会出现。

 

l 因为原型开发是一种低成本的快速构建，那么好的原型工具可以事半功倍。好的原型工具要满足以下要求：

1.          完全可视化，所有的控件都是拖拽到页面上即可。

2.          简单的事件响应，例如点击下拉框出现列表；点击按钮弹出提示框。

3.          能够做到简单的流程跳转，例如支持按钮点击之后跳转到另一页面。

4.          能够方便地填写mock数据。

5.          最好支持脚本。

 

直接用VS做原型设计也不错。