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

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

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

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

在编写故事之前应该建立用户角色模型，必须包含对项目成功至关重要的角色，尽量保证所有用户对系统完全满意。

如想创建优秀的故事，需要认真领会 6 个属性，分别是：独立性、可协商性、对用户或者客户有价值、可预测性、短小精悍，以及可测试性。 Bill Wake 使用缩写词 INVEST 表示 6 个属性 ^:

1 ）独立性。尽可能避免故事之间存在依赖关系，故事间依赖关系会产生优先级和规划问题。

2 ）可协商性。故事是可协商的，不是必须实现的书面合同或者需求。

3 ）对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。

4 ）可预测性。开发者应该能够预测（至少大致猜测）故事的规模，以及编码实现所需要的时间。

5 ）短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开发组规模、开发组的能力，以及技术实现等方面。

6 ）测试性。所编写的故事必须是可测试的。

 

      与用例的区别

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

1 ）范围不同。二者都用来体现商业价值，但故事规模可以设定比较小（例如， 10 天完成），以便以此为单位安排工作。用例包含的范围可能比故事大得多。

2 ）完成程度不同。 James Grenning 曾指出：故事卡中的文字“加上验收测试用例就基本等同于用例”，这意味着故事对应于用例的基本流，而故事的测试要求对应于用例的备选流。

3 ）寿命不同。用例通常是持久的工作产品，在产品开发和维护时，用例一直存在。然而，故事通常只存在于实现该故事的迭代中。虽然故事卡可以存档，但是许多团队都将故事卡销毁。

4 ）编写目的不同。用例的目的是记录客户和开发团队的一致意见。故事是为了便于制定发布计划和迭代计划，并作为有关用户需求细节方面的交谈备忘录。 

 

这里我们将选择用户故事来驱动后续工作的进行。