业务模型驱动需求编写

王大锤老师在上BA课的时候，经常会用一个俄罗斯方块的例子：请描述俄罗斯方块旋转的逻辑。由于俄罗斯方块有好几种不同的类型，每个类型又有4个角度，因此组合起来有数十种可能的场景。如果用IF- Then去描述，很快就陷入困境。然后大锤老师给出答案：实际上每个俄罗斯方块是一个4*4的矩阵，矩阵中有一些方块是空，有些不是空（下图）。对方块的旋转就是对矩阵的旋转。一旦选择了合适的模型，然后使用这个模型去描述需求，顿时问题就变得简单了。

我看到很多采用了用户故事实践的团队，在描述用户故事的时候，仍采用UI原型的方式进行。代办事项里充斥着各种XX页面，YY功能之类的名字。在进行需求讲解的时候，也会一上来就是拉出各种界面。这种方式会导致开发人员很难一下子掌握这些需求的背后业务，还需要进行一次消化理解。而由于两者缺乏必要的沟通，会导致双方对业务理解有偏差，进而实现的模型和业务模型有偏差，导致两者不匹配，新的需求变更很难完成。

用用户界面去描述需求，就好比用一个个格子去描述俄罗斯方块。也不是完全不能描述，只是如果按此进行建模，那么实现起来就会异常困难，对需求变更的响应也会非常困难。在哥白尼日心说之前，是地心说统治世界。但后来按观察到的行星运动去套到地心说的时候，会发现运动规律及其复杂（下图）。而只有按日心说去描述行星运动，才会变得一目了然地简单。

因此，为了更好描述业务，以应对将来发生的变化。应该以业务对象为核心去描述业务。业务对象包括单据、凭证、申请表等实体。角色对业务对象的操作就是用户故事。一个用户故事应该包括一个角色、一个业务对象、一个操作。在此基础上，我们才需要进一步说，为了满足这个操作，我需要什么样的界面提供给用户来完成这个操作。UI从描述业务的中心，退居到为了满足业务的细节。这样我们在前期，只需要UI草图，而只有进入到正式开发了，才需要对UI细节进行设计。

也有人会说，业务建模没有对错。确实如此，一个业务有多种模型可以描述。但业务建模有好坏，好的模型体现了业务的本质，只要业务不变，新的需求很容易满足；坏的模型只是理解了表面，仅仅解决了当前问题，一旦有新需求，就会让软件难以修改。