敏捷管理中的史诗与故事

在敏捷软件开发中，史诗＆故事都是经常使用的术语。对于管理敏捷软件开发来讲，Choerodon猪齿鱼是一个很好的工具，为敏捷术语和功能提供了很是普遍的实践方法，例如：史诗，故事、任务、子任务和缺陷，这些都是Choerodon中的问题类型。

• 史诗：是一个功能集或是一个大的用户故事，但由于颗粒度太大而没法适应冲刺，它能够分解为许多较小的故事；
• 故事：是简短的用户需求，足够小以适合冲刺；
• 任务：是完成用户需求的过程性的工做，表示用户故事开发任务的完成；
• 子任务：子任务一般是故事或任务的具体拆分，由单人承接，并且一般能在短期内完成；
• 缺陷：主要针对测试中的缺陷或者已发布版本的缺陷；

本文将详细为你们介绍敏捷中史诗和故事以及它们在敏捷中的具体使用规范。

什么是史诗？

史诗是一个大的故事，当一个功能具备多个场景时，该功能则须要在史诗层面进行多种实现。史诗表明的一般是与特定结果密切相关的原始想法，与该史诗相关联的用户故事则表明须要交付的解决方案的各个方面。总的来讲，经过史诗能够跟踪待办事项中比较大的用户需求，史诗中包含多个小的产品功能的用户故事，这让用户需求更加具备层次结构。

如何编写史诗？

对于史诗的编写，目前尚未标准格式，一些团队会使用熟悉的用户故事格式，也有一些团队则用简短的短语表示史诗。

在命名史诗时，请牢记如下两点：

1.它是开发或需求的核心内容；
2.编写时使用组织中的每一个人均可以理解的语音文字，以避免产生歧义；

由于史诗是编写用户故事时要参考的内容，而且在编写用户故事时还要参考全部团队成员的意见，因此正确的编写史诗并将详细信息在史诗中体现很是重要，这有助于避免团队中的许多冲突和对产品功能的误解。

用史诗介绍开发的新功能时，须要包括开发此功能的缘由、须要解决的用户需求以及新功能的度验收量标准。此外，该功能的任何文档或早期的思路，能够向团队简单介绍，或者提供清晰的图片和信息。注意：团队对功能达成共识和目标是成功交付的关键。

Choerodon中的史诗示例：

• 史诗01：向用户提供排序和优先级选项，以轻松管理需求

  • 用户故事01：做为发布经理，我但愿将发布映射到不一样的sprint，并看到每一个故事的优先级。
  • 用户故事02：做为系统管理员，我拥有优先处理产品需求的权限。
  • 用户故事03：做为用户，我能够标注需求的优先级，并实现简单的拖放操做从新排序需求。

编写史诗时须要注意的是：

1. 谨慎思考

在编写史诗时，能够先撰写项目构想的草稿，并须要思考最有必要的内容以及在之后的开发中包含的内容。这些都须要仔细考虑。

1. 逻辑清晰

在编写后续的史诗时，应该根据先前的主题来建立史诗，先后的史诗须要合乎逻辑且一致。

1. 结合测试

史诗不仅是从大的故事进行思考，它分解的每一个功能还须要在测试中可用。

1. 参考专家人士的意见

在编写过程当中不该仅依靠我的或团队成员的眼光和思路，还须要参考专家人士的意见，阅读专业人士的的博客或他们推荐的书籍。他们的工做经验和意见能使史诗更加客观，也能让团队成员得到专业的经验和技能。

史诗是项目计划过程当中重要的组成部分，有了史诗，团队成员和利益相关者能够看到产品真正的目的和用户需求。正确的史诗是进一步项目开发甚至产品研发的好帮手。

什么是用户故事？

用户故事是基于史诗进行分解的，反映的是用户需求和用户能够获得的价值。它们从用户的角度描述功能的各个部分。在敏捷开发过程当中，当咱们开始站在用户的角度上思考时，即便这个功能不是当前解决方案的范畴，咱们仍须要创建用户能够操做的行为场景。例如，咱们正在针对共享照片和视频的特定问题制定解决方案，根据经验咱们按照预期的方式执行全部操做，可是用户第一次使用而且不了解产品，可能查找不到特定角色对应的照片。为了不这种状况，在用户故事中从用户角度清楚地说明所需的功能很是关键。

如何编写用户故事

在敏捷方法论中，团队构建的全部内容都应围绕用户，这里的团队指的是产品经理、客户、利益相关者还有产品的最终用户。为了深度了解用户的需求和痛点，在开始编写用户故事以前，须要肯定好产品的角色。如下是编写用户故事时普遍使用的模板：

“ 做为一名 <角色或角色>，我能够 <目标/须要> 这样说 <为何>”
或者，在另外一种状况下：
“做为 <特定的用户类别>，我但愿 <可以执行/执行某项操做>， 以便 <得到某种形式的价值或收益>”

上面的描述为产品用户制定了业务价值。除此以外，用户故事的魅力在于，它不只制定了业务价值，并且还制定了开发和测试的要求。经过简单的描述，添加产品功能的验收标准等描述，以总结须要完成的全部任务。

如下Choerodon中某个项目的用户故事的简短形式：

做为夜晚驾驶的驾驶员，我想迅速找到最近的优质加油站，以补充高品质的汽油。

• 验收标准：

  • 做为开灯的司机，我能够看到全部即将到来的加油站。
  • 点击“Ctrl+T”，我能够选择适合个人加油站品牌的加油站。
  • 到达加油站，我能够看到即将到来的选定品牌的加油清单。
  • 点击“M”键，我能够看到最近在地图上选择的加油站。

用户故事的重点是从用户的角度清楚地说明所需的功能，须要正确的理解用户需求并详细的表达出来。编写用户故事时须要注意：

1. 用户故事≠任务

用户故事不是任务。在实际开发中，一个故事可能须要数百个任务才能成功交付，任务与执行有关，而用户故事是根据用户需求定义的。在编写故事时，应着重于提供有关产品功能的信息。

1. 故事简明扼要

故事必须简单而准确。只需使用简单准确的语言便可，有助于团队成员和利益相关者深刻了解用户需求，避免花时间澄清用户故事中不清楚的地方，好比术语和首字母缩写词等。

1. 了解用户

在开始编写用户故事以前，都须要收集一组关键用户（理想状况下是产品的角色用户），了解他们的我的资料、观点、对产品的指望以及相关的“痛点”，以帮助更好地了解用户及其需求。

1. 大胆思考

当将产品描述为用户故事放到待办事项中时，“没有预算，时间周期不容许，可行性低或成本高等”会限制产品的思惟。正确的作法是大胆思考 ，将用户故事维护到待办事项列表，从产品的清晰度、用户愿景方面得到的价值。

用户故事提供了一种快速而准确地描述软件产品或系统功能的好方法，在产品规划会、产品迭代会中具备主导和输出做用。在这些会议过程当中，用户故事须要以紧凑、结构化的方式阐明思想的提要。

故事地图

根据敏捷的定义，在Choerodon中咱们使用故事地图的形式来体现史诗和用户故事的价值。

故事地图的优点：

1. 将史诗用做业务价值的容器；
2. 根据产品版本获得横向流程；
3. 快速制定出产品的蓝图，获得mvp版本的制做周期；（关于MVP的介绍能够参考《MVP：平衡“可行性”和“最小化”》）；
4. 以故事为中心，使开发人员的精力所有集中到重点功能上；
5. 使用增量来按期检查并调整项目进度；

总结

敏捷开发关注于快速且持续地交付给用户高价值、高质量、可用的产品功能。经过史诗和用户故事梳理用户需求、识别用户角色、梳理用户故事逐步完善更多细节，使执行的故事足够短小、简单，能在单个迭代期内完成，达到快速交付的目的。

本篇文章出自 Choerodon猪齿鱼社区付新圆&柴晓燕。