(https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f))
<001 篇>
我经常出差,接触了大量的华为云的客户,很多客户使用项目管理服务,对Epic都比较陌生,也对如何划分Feature,Story存在疑问
为了,我特意整理了一个表格,对每一种工作项类型进行了说明,为了解决很多用户的疑惑,我也增加了样例说明
简单一句话:
-
Epic是公司重要战略举措;
-
Feature是对你的用户有价值的功能;
-
Story是分解的细粒度的开发交付的内容,是用户的细分场景;
-
Task是完成需求的过程性的工作。
这些术语和概念,来自于业界的共识,对于软件企业,是实现从战略举措到战术执行落地的分层设计。
表格
工作项类型 | 说明 | 举例 |
---|---|---|
Epic | 中文通常翻译为史诗,指公司的关键战略举措,可以是重大的业务方向,也可以是重大的技术演讲.企业通过对Epic的发现、定义、投资、管理和落地达成,使得企业的战略投资主题得以落地,并获得相应的市场地位和回报。 Epic的粒度比较大,需要分解为Feature,并通过Feature继续分解细化为User Story来完成最终的开发和交付。 Epic通常持续数月(months),需要多个迭代才能完成最终的交付。Epic应该对所有研发人员可见,这样可以让研发人员了解他们交付的Story承载怎样的战略举措,让研发人员能更好的理解其工作的价值。 |
Epic通常和公司的经营、竞争力、市场环境紧密相关,举例如下: 例1 市场差异化:用户体验全面超越竞争对手 例2 更好的解决方案:新增支持工业互联网的解决方案 例3 增加收入:产品需要在下个财季增加100万付费用户 例4 重大技术方向:产品需要全部切换为容器 |
Feature | 中文通常翻译为特性,代表可以给客户带来价值的产品功能或特性。 Feature向上承接Epic,向下分解为User Story。相比Epic,Feature更具体形象,客户可以直接感知,通常在产品发布时作为ReleaseNotes的一部分发布给客户。 Feature通常持续数个星期(weeks),需要多个迭代完成交付。 |
Feature应该对客户都有实际的价值,特性的描述通常需要说明对客户的价值,与产品的形态、交付模式有关,举例如下: 推荐模板:用户<角色> …希望<结果>… 以便于<目的> 例1 用户A希望提供导入、导出功能,以便于用户批量整理数据,更高效。 例2 用户B希望提供超期的邮件通知,以便于用户及时处理任务。 例3 用户C希望优化鼠标拖动的体验,以便于让用户操作更快。 例4 用户D希望增加昵称功能,让用户更个性化。 |
Story | 中文通常翻译为用户故事,User Story的简称。是从用户角度对产品需求的详细描述,更小粒度的功能。Story承接Feature,并放入有优先级的backlog中,持续规划、滚动调整优先级,始终让高优先级的Story更早的交付给客户。 优秀的Story应遵循如下的INVEST原则: Independent:每个用户故事应该是独立的,可独立交付给客户。 Negotiable:不必非常明确的阐述功能,细节应带到开发阶段跟程序员、客户来共同商议。 Valuable:对客户有价值。 Estimable:能估计出工作量。 Small:要小一点,但不是越小越好,至少在一个迭代中能完成。 Testable:可测试。 Story通常持续数天(days),并应在一个迭代内完成交付。 |
Story符合INVEST原则,举例如下: 推荐模板:用户<角色>…希望<结果>…以便于<目的> 例1 作为项目经理,希望通过过滤处理人,以便于快速查询指定人的需求。 例2 作为开发人员,希望将无用的信息进行折叠,以便于减少视觉干扰。 例3 作为测试人员,希望将测试用例和需求关联,以便于跟踪需求的验证。 |
Task | 在迭代计划会议中,将纳入迭代的Story指派给具体成员,并分解成一个或多个Task,填写“预计工时”。 | Task通常为过程性的工作,举例如下: 例1 开发人员A需要在今天准备好类生产环境。 例2 开发人员B需要在本周末完成项目组的权限设定。 例3 开发人员C需要进行代码Review。 |
网友评论