我们在进行敏捷项目管理的时候,最重要的就是要让团队对所推进的项目有一个共同的认知。无论是大到宏观上的战略目标,还是小到一个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后,从产品的角度上来讲可以更清晰的表述出所需要实现的功能,从开发的角度上来说也更便于识别出哪些是核心功能而减少加班,甚好甚好。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.