网友的来信:
最近在拜读您的大作《大象》,收益良多,
先介绍下问题的背景,我从事的产品以web界面为主,
问题就产生于这样的产品开发流程中,
关于这样的问题,个人理解,归结到底,
另,还在学习中,如有疑问的产生还希望得到您的继续指教,
我的回复:
你好。用例当中有关于UI设计的内容,
在RUP当中称为用例示意板。
在实际操作当中往往用界面原型进行描述,
如您的产品以WEB为主,
那么使用静态html配合用例规约就是比较适合的方法。
在你所描述的情况当中,交互信息、
异常情况是应当尽量考虑清楚的,但是不论如何仔细,
永远都不可能做到事事具备。
如果花费过于大的精力去描述用例的各个方面,
把争持认为是用例规约没有描述清楚,
很容易走入过度设计的死胡同。
我不相信谁能够保证把用例规约写到没有万一的地步,
那不符合软件规律。
所以,我们要接受现实,不是用例规约出了问题,
而是实施方法出了问题。用例不仅是分析人员的事,
也是测试人员的事,也是开发人员的事。在实施上,
他们都应当参与进来,而不是等待分析员的结果。
在决定一个用例规约的时候,测试人员就应当能够产生测试用例,
对于模糊地带,在讨论用例的过程当中来进行澄清。
RUP之所以使用迭代的开发方法,
就是要在每一个迭代时重新审视、修改用例规约,
让各方都参与进来,把模糊地带搞清楚。
请告诉你的同事们,用例规约的责任不仅仅是产品设计人员的事,
也是开发,测试的事,他们也是责任者而不仅仅是使用者和旁观者。
争执是不可避免的,
但是争执如果发生在用例讨论过程当中而不是产品开发和测试时,
争执就是好事情而不是委屈了。
最后再做一点补充:
在一个敏捷的团队里,一个用例就相当于一个work item,或者一个task,或者一个userstory,不论叫什么名字,这个用例是由整个团队来维护的讨论的,不同职责的成员关心它的不同部分,但大家讨论的是同一个用例。在迭代的过程中,这些讨论被不断的深入,一个一个的模糊地带被不断的澄清,大家对同一个问题越来越清楚。当必要的改变发生时,大家分别负责改变自己的部分。最后,需求部分、分析部分、设计部分、代码、测试用例、测试代码、测试结果、缺陷纪录、变更纪录....所有围绕用例产生的东西都成为了用例的一个组成部分。
可见,用例规约不是一开始就事无巨细的。这位网友的问题其实是在软件过程中产生的,非常普遍,方法好讲,解决起来并不容易。关键是要建立一个自驱动的团队,大家都意识到用例是所有人的,软件过程是迭代的而不是瀑布的,这样,用例驱动的意义才能够体现出来。