赴美生子 月子中心 美宝论坛

敏捷实践--用户故事和用例的选择

    用户故事描述了对软件(或系统)用户或客户有价值的功能。用户故事包括三方面内容:书面描述(用于计划和备忘),交谈(细化故事细节),以及测试用例(验证故事实现)。用户故事描述的传统形式是手工书写的用户故事卡, Ron Jeffries称如上三方面内容为Card(卡片)Conversation(交谈)Confirmation(确认)。     

     用户故事一般包括3方面的要求:作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)。比如仓库管理中有这样一个想法:仓库操作人员想通过使用手持设备完成仓库的拣选商品的操作,以提升仓库工作人员的工作效率。其中受众是仓库操作人员,业务操作是使用手持设备进行商品的拣选,目的是提升仓库操作人员的效率,实现商业目标。

     开发者辅助客户编写故事,告诉客户所编写的故事是进一步讨论的引子,而不是详细的需求规范。在任何项目中,需要客户团队根据故事的重要性来安排开发者的工作,回答所有开发者的问题,编写所有的故事。客户团队包含多个成员(诸如测试人员、产品经理、真实用户、交互功能设计人员),确保软件满足目标用户的需求。

在编写故事之前应该建立用户角色模型,必须包含对项目成功至关重要的角色,尽量保证所有用户对系统完全满意。
如想创建优秀的故事,需要认真领会6个属性,分别是:独立性、可协商性、对用户或者客户有价值、可预测性、短小精悍,以及可测试性。Bill Wake使用缩写词INVEST表示6个属性:
1)独立性。尽可能避免故事之间存在依赖关系,故事间依赖关系会产生优先级和规划问题。
2)可协商性。故事是可协商的,不是必须实现的书面合同或者需求。
3)对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。
4)可预测性。开发者应该能够预测(至少大致猜测)故事的规模,以及编码实现所需要的时间。
5)短小精悍。故事规模对实现有影响,何种故事规模最合适,取决于开发组规模、开发组的能力,以及技术实现等方面。
6)测试性。所编写的故事必须是可测试的。

 

      与用例的区别

     用例最早由Ivar Jacobson1992年提出,用例通常与统一软件过程相联系。用例描述系统和角色之间的交互。两者差别主要在于:

1)范围不同。二者都用来体现商业价值,但故事规模可以设定比较小(例如,10天完成),以便以此为单位安排工作。用例包含的范围可能比故事大得多。
2)完成程度不同。James Grenning曾指出:故事卡中的文字“加上验收测试用例就基本等同于用例”,这意味着故事对应于用例的基本流,而故事的测试要求对应于用例的备选流。
3)寿命不同。用例通常是持久的工作产品,在产品开发和维护时,用例一直存在。然而,故事通常只存在于实现该故事的迭代中。虽然故事卡可以存档,但是许多团队都将故事卡销毁。
4)编写目的不同。用例的目的是记录客户和开发团队的一致意见。故事是为了便于制定发布计划和迭代计划,并作为有关用户需求细节方面的交谈备忘录。 
 
这里我们将选择用户故事来驱动后续工作的进行。
 
 
posted @ 2008-11-03 20:32  SuperBowl  阅读(1783)  评论(0编辑  收藏  举报