敏捷项目管理-Epic Story是个啥？

我们在进行敏捷项目管理的时候，最重要的就是要让团队对所推进的项目有一个共同的认知。无论是大到宏观上的战略目标，还是小到一个user case。统一认知可以尽可能避免由于认知偏差而引起的bug和需求返工。看起来Epic Story能帮我们，但是它是怎么做到的呢？

Epic方法是个啥？

简单来说，就是讲一个宏大的史诗(Epic)故事，从而可以让所有人从这个故事中理解作者的本意。Epic Story是一种通过不断拆解项目而便于所有人统一认知的项目描述方法，它通过不断对同一核心的概念的拆解，将需要工作的“条目”逐渐明确。而这些条目一般来说是由Epic，Feature，Story，Task构成。

Epic怎么拆？

Epic：

Epic是一个总的目标，所有人都需要朝实现Epic进行努力。例如：用户中心。注意Epic本身也是Story，所以Epic本身也可以用一句话来描述，例如：作为一名用户，我需要一个用户中心，来查看我在本系统中的个人信息相关的内容。

注意，需求中Epic是要具有商业价值的内容，该商业价值是驱动项目进行的衡量标准，如果Epic不能解释为商业价值，那么它并不是一个有效的Epic。

Feature：

Feature是从Epic中拆解出来的特性内容，Feature将支撑Epic中的全部内容。Feature一般是针对Epic中需要实现的功能，表示了如果要实现Epic需要的若干能力。一个Feature往往相对复杂，可能会由多次迭代才完成。而由于Feature是产品的功能特点，所以对于功能交付内容来说，就应是对应一个或者多个Featrue的。

User Story US：

us是用于补充对FE的描述的，用一句话从一个用户（user）的角度上来描述一个FE中的特点。一般来说，us是使用 As a xxx, I need xxx ,as than xxx 的句式来进行表述。从而阐述"谁 需要什么 以便什么"。

例如: 作为文档编辑者，我希望文档修改后，在退出编辑时提醒我保存文档，以便我不会丢失数据。

us具有可验证性，us中表述的功能点可以作为测试同学的case，或者是产品同学的验收功能点。

对于一个能力，如果无法通过"As a xxx, I need xxx ,as than xxx"的句式来描述，那么说明：

1. 缺少受众：这种能力没有没有人需要；

2. 这种能力不是紧扣Epic主题的，不应该在本FE中进行设计开发。

而如果一个us仅通过一句话无法讲完，则说明该us是可以继续进行拆分。

User Story具有以下六大特点(INVEST)：

· Independent：独立的

· Negotiable：可变的

· Valuable：有价值的

· Estimable：可估算的

· Small：足够小的

· Testable：可验收的/可测试的

TASK：

当一条us中对于实际的工时评估无法具有直观的概念的时候，可以由开发人员将us拆解为具体的task内容。便于体现出实现us中的必要隐藏步骤，作为实际功能开发时长的支撑。注意，task可能并不是直接实现us的内容，比如"设计评审会"也可以是us的一个task。

Epic全盘接受吗？

对项目进行了Epic拆分，那所有的结果开发同学就要照单全收吗？那必不能如此。

做哪些？

因为在实际版本开发的时候，交付是针对FE进行，所以根据FE中us的I need的急迫程度，以及 as than 的重要程度，可以将FE划分为P0，P1，P2等不同等级，那么就可以只做P0，考虑P1，不做P2。

如何判断急迫程度？

目前考虑到以下几种情况：

need 事务的重要程度，比如“作为用户，我需要下单，来购买我需要的商品。”和“作为用户，我需要收到短信提醒，来确认我下单完成了。”这两个us来进行比较。就需要评估"下单动作"和"通知动作"的重要程度。当下单和通知在一起被提出来的时候，一般来说下单优先级会高很多。

当as than xxx重复的时候，例如：“作为用户，我需要收到短信提醒，来确认我下单完成了。”与“作为用户，我需要收到短信提醒，来确认我下单完成了。”他们是同时支撑了一个目的，而相对来说其价值就降低了。

不做的需求怎么办？

并不是永远不做，要不就该被产品同学连夜追杀。一般来说当支撑一组US已经可以支撑起一个FE的时候，那么说明功能已经可以上线。那么之前剩下的US则可以组成一个新的 FE（在有必要的情况下），例如 FE"用户下单体验"，则之前不做的US"作为用户，我需要收到短信通知，来确认我下单完成了"就变成来支撑新FE的US，那么对于这个FE来说这个US就是P0级别的了。

但是这个FE的重要程度，就需要在kickoff中和其他的FE比较，看谁对于EPIC的支持力度更大了。

做多少？

需要产品先确定要做的FE，然后将FE拆分为us，根据us来评估工时。然后根据实际的开发人力，挑选核心满足需求的us来进行开发。如果工时限制那么就只能减少非核心us，如果核心us数量确定则只能延后上线时间。以最大化商业价值为核心思想。

最后

Epic方法拆解为了对应的us后，从产品的角度上来讲可以更清晰的表述出所需要实现的功能，从开发的角度上来说也更便于识别出哪些是核心功能而减少加班，甚好甚好。