敏捷用户故事概览

[ditunes]

敏捷用户故事概览

• 定义：从用户或系统购买者角度阐述对其有价值的功能。
• 核心内容：卡片(card)、对话(conversation)、确认(confirmation)【Ron Jeffries提出的3C要素】
• • 卡片：用简短的言语表示用户的需求与价值
  • 对话：用户代表与工程人员之间通过沟通确认需求细节
  • 确认：记录双方在沟通中确认的功能细节。一般而言，以编写具体故事细节或者测试以确定功能已经开发完毕。
• 核心要素：作为（角色），我想要（功能），以此（用户价值）
• • 角色
  • 活动
  • 商业价值
• 卡片内容：
• • 功能名称：作为（角色），我想要（功能），以此（用户价值）
  • 优先级：用数字表示优先级大小，越大的数字优先级越高
  • 故事点：表示故事规模，数值越大表示该故事表示的功能越复杂，需要较多的开发时间。它不应当理解为耗费工时，它只是表示难易度。即故事点为4是故事点为2的两倍，但不表示4个理想工作日完成。
  • 如何演示：能够向开发团队表述故事意图的测试（不需要过于详细）比如注册时候的手机号只能为中国区，不得为外国区。
  • 注释：记录对话中的需要关注的要点
• 用户故事在项目开发中的意义
• • 将团队工作紧密围绕于用户价值最大化这一目标：凸显用户价值信息有助于团队工作效益最大化，有助于在纷杂的功能列表中筛选优先级最高的任务。
  • 提升团队沟通效率：团队成员将可以围绕某一用户故事开展细致讨论，既可以避免沟通缺漏，也可以在沟通中加深双方对功能细节的理解。
  • 有助于团队任务的追踪与规划：团队成员可以通过用户故事为入口拆分成工作任务。项目管理人员也可以时刻跟踪故事下的任务完成进度情况。
• 优秀用户故事特性（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable）
• • 独立的：
  • • 避免故事之间相互依赖，即A故事需要在B故事之前完成，或者A故事完成后，需要对B故事的规模进行重新评估。
  • 用户故事必须是完整的，并发挥可对用户发挥价值，任何不完整的故事是无意义的。
  • 可讨论的：不一定需要大量的细节，鼓励干系人在讨论中确定细节。
  • 可估计的：开发人员可以估算出开发所需要执行的任务与时间量。
  • • 开发人员不懂领域知识：及时与客户团队或代表进行沟通学习
  • 开发人员不懂新的技术：使用探针试验，将无法估计的故事拆分出一个试探性学习故事在一个时间盒子内以求了解新领域的大致情形，形成评估能力。
  • 故事规模过大：将故事根据数据边界、操作方式进行切分。
  • 对用户或客户有价值：切记我们的出发点是客户，我们的描述一定是基于客户立场。
  • 小的：用户故事大小应该适当，有助于团队成员做细致评估分析。而过小的故事可以合并为一个较大故事。请注意：大的故事表示一个暂时不需要或延后分析的功能需求。
  • 可测试的：用户故事只有保证可测试性，才能确保故事被成功实现。
• 编写用户故事核心准则
• • 明确用户角色：拒绝用用户这个词表示用户，应该使用具体角色如求职者、普通员工等
  • 只为单一用户角色编写故事：一个故事中最好只有一个用户角色，可以保证用户故事表达的准确性。
  • 用主动语态表达用户故事：
  • • bad：简历被求职者发布
  • good: 求职者发布简历
  • 切记用户故事卡片是为了引起团队针对功能对话：不要再卡片建立初期关注过多细节，它只是起了一个会话入口或索引的所用，更多的细节是在对话中，进一步确认。
  • 合理切分用户故事：将过大的用户故事切分小的、完整的、有价值的用户故事，同时保证可以装入一轮迭代周期之中。切记：小的故事也是对用户有业务价值的
  • • bad：完成pc 端ui界面设计
  • good ： 求职者可以使用pc网页版完成简历发布。
  • 编写封闭故事（待延展）
  • 不要让故事过早涉及用户界面
  • 约束类型的用户故事：在故事卡片加上约束备注，这种约束型的故事可以用来描述项目非功能性需求，它可以不纳入迭代且不需要评估，但是可以提醒团队成员注意约束，同时指引团队为此编写测试。
  • 避免使用技术语言来描述用户故事