2     准则

用户故事地图要素：

构建用户故事地图需要：时间线，用户活动，用户任务，用户故事，故事地图结构：用于实现目标的用户功能  >  活动  >  任务  >  史诗  >  故事

• 将用户要素从左向右拖动到地图的顶行。地图顶行中的每个功能都是呼叫用户活动。

• 创建完成活动所需的许多步骤，称为用户任务。

• 这些用户任务中的每一个都可以分解为多个史诗。

• 在史诗下，可以定义用户故事列表，其大小适合放入sprint。

用户故事的3C原则

3C原则是由Ron Jeffries提出的。它包括三个部分：

Card卡片，用来简要描述软件特性或改进点。

• 描述的内容简洁、词汇含义统一，项目成员不会对同一内容有差异性理解；

• 这些卡片用于后续的沟通、对需求内容的组织和排列优先级；

Conversation 交谈 ，与Product Owner（或客户）交谈来明确细节。

• 卡片的内容是由团队在沟通中获得，而非由同一个人输出或更新的，不然它与传统的需求分析方法无异；

• 项目成员需要一起就卡片内容进行讨论。在复杂逻辑中，梳理出清晰的需求脉络，并在这一过程中，达到共识和理解的统一。

Confirmation 确认，每个故事应具有验收标准（验收条件），能够确认被正确完成。

• 以始为终，先行确认以怎样的结果，来判断开发任务的完成；

• 它保证每个故事都是独立的、完整的逻辑，可以单独交付；

• 它为驱动测试驱动开发、行为驱动开发和持续集成提供可能。

用户故事原则：

• I 独立的（Idependent）：独立且完整，不依赖于其他任何用户故事；

• N 可谈判的（Negotiable）：引导团队跟干系人之间对话和谈判的介质。在任何时候，用户故事都可以被改写甚至丢弃。一个用户故事不会像石头一样固定不变，直到它将要在接下来的Sprint里被实现；

• V 有价值的（Valuable）：需要将价值给干系人，不论是最终用户还是采购者；

• E 可估算的（Estimable）：团队需要能够粗略地估算出完成用户故事所需工作量规模；

• S 小规模的(Small)：以一个大的“占位符”开始其生命周期。随着时间的推移，当人们对用户故事所表达的愿望的复杂度更加了解时，这个较大的“占位符”就将被拆分成小的用户故事。当最重要的那些用户故事将进入Sprint被实现并交付时，它们需要变得足够小，这样才能在一个Sprint里被完成。

• T 可测试的(Testable)：一个用户故事必须提供必要的信息，清楚地界定了故事的验收标准，这样才能在它完成时判断是否验收。

3     创建用户故事地图