怎样对一个产品编写完整的用户故事( 三 )


怎样对一个产品编写完整的用户故事

这一部分需求,产品经理会通过后台查看,分析评估之后,考虑在对应项目的需求规划中响应。
二、需求实现1、产品经理会在对应的项目中按照史诗-特性-用户故事的层级,对整个产品的功能框架进行整体的需求规划。
怎样对一个产品编写完整的用户故事

2、对已规划的需求进行优先级的排序,来确定正在进行中的史诗里,哪些特性需要在接下来的版本进行发布。将其规划入对应版本。
怎样对一个产品编写完整的用户故事

怎样对一个产品编写完整的用户故事

3、将进入发布版本的特性拆分为用户故事,对用户故事进行估算以后,按照迭代容量安排开发计划。
怎样对一个产品编写完整的用户故事

4、进入迭代的用户故事会按迭代周期进行交付,更新特性的进度。特性验收完成后更新所属史诗的进度。由下而上的推进整个产品的开发进度。
怎样对一个产品编写完整的用户故事

怎样对一个产品编写完整的用户故事

通过对不同层级需求在不同维度上进行管理,使得整个需求管理流程更清晰流畅,极大程度的提升了需求管理的效率,聚焦了产品目标。
Worktile - 软件开发、项目管理及协作工具

■网友
若是从敏捷开发的角度来看,用户故事本身一定不会完整。它的作用应该是引起交互设计师,产品经理,客户,还有开发团队进行谈论的一个点。完整故事,会通过故事的澄清不断完善,敏捷所倡导的不是这样么。有次跨部门分享中,有位同事说到几点,觉着还不错,当时也记下来了,贴出来1、用户故事;为什么要有一条用户故事?一定是说明问题,提出解决方案,明确解决效果。要用简洁的语言,说对有用有价值的需求,是外在的行为。 2、用户故事的模版;角色定义(我是谁)+期待(我要什么?)+原有/目的(我为什么会这样) 3、开发工程师的疑问咬文嚼字,对故事一定要在语言上进行提炼要对开发工程师宣导用户故事中创造的价值 4、检验用户故事的标准(教材中也有提到的五点)独立的可协商的有价值的小的,可在一轮迭代中完成的可测试的 5、关于用户故事的几句有用的话可测试的用户故事,是否明确了有极限值和边际成本验收条件中是否包含了新的用户故事描述是否从用户的角度中进行
■网友
敏捷 1.0 Scrum+XP 中常用的用户故事(User Story)通常是写在一张故事卡片上的:怎样对一个产品编写完整的用户故事

(网源图片)设想要把一个完整的用户故事写下来,尤其那些描述复杂产品需求的用户故事,一张卡片怎么够?可能卡片背面也不够。那那么多需求细节写不下怎么办?可能很多敏捷 1.0 的粉不知道,用户故事的正宗、经典用法是:口述需求!正因为在 XP 的起源项目 C3(克莱斯勒薪资项目)中有 Onsite Customer(另一个关键的 XP 实践),产品经理天天就在开发现场,所以 PM 可以随时随地地向开发口述、阐释需求的各种细节,而故事卡片只是起到了一个 placeholder 或 reminder(提示器)的作用,需求有什么不懂、不清楚的地方让开发拿着这张卡片去问 PM 就是了。大家一边讨论需求,一边写测试、写代码,甚至,PM 还能亲自动手帮你写产品测试、做测试,保证产品符合用户需求,这真的是一个很理想的场景啊。所以,XP 项目有用户故事卡片加测试就够了,不需要详细的 PRD 和需求模型。用例故事你非要把一个完整的用户故事,不用口述而用文字编写下来么?那么我告诉你一个 Agile 2 的最佳实践(之一):1)为这张用户故事卡片取一个合适的名称(通常是动词词组);2)把这个用户故事名称所对应的用例故事|使用故事(use case,or use story)写下来,这就是你想要的完整的用户故事。针对是购物搜索网站,“搜索”是否应该单独作为一个故事来描述。Search anything 作为一个单独的用户故事,可能过大了是一个 theme 或 epic story(实现估计超过 2 周),可以分解为粒度更合适的用户故事,例如 Search goods, Search sellers 等等。如果还是太大,继续分解。


推荐阅读