江苏龙网

  1. 首页 > 生活 > >

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


用户故事的标准格式接下来，简单介绍一个写用户故事的INVEST标准，满足这个标准的用户故事一般就是OK的。
怎样对一个产品编写完整的用户故事

写作要素和标准
角色：谁要使用，为谁而设计？功能：这个功能是有什么作用，要达到什么程度才算发挥作用？商业价值：为什么要这个功能，能带来什么商业价值，对用户有什么意义？用户故事格式：作为一个 XXX, 我想它实现 XXX, 以便于 XXX。怎样对一个产品编写完整的用户故事

独立（Independent）：要尽量避免故事间的相互依赖，相互依赖会导致工作量估算更加困难。
可讨论（Negotiable）：条目的细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是一个写死的具体的规范。
有价值（Valuable）：用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。
可估算（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量和工作计划。难以估计故事的问题来自：
开发人员缺少领域知识和业务相关背景；开发人员缺少技术知识；故事太大了。大小合适（Small）： 一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。
可测试（Testable）：故事必须是可测试的。成功通过测试证明了开发人员正确地实现了故事。如果一个用户故事不能够测试，那么我们就不能确定它可以被称为完成。
更多相关内容传送门，我附赠在下面，不再做过多赘述，需要可以自行移步：
Galaxy：追本溯源，用户故事（UserStory）与用例（UseCase）的区别浅析如何理解“产品需求”和“用户需求”？Galaxy：初学者终极指南-掌握Scrum敏捷框架-第6章另外关于更多敏捷和软件工程实践，SAFe4.6框架中文版等，可以移步我的专栏
Scrum敏捷精益开发完全原创，长文不易，送个关注/赞同吧~

■网友
我回答个跑题的答案。
我觉得怎么编写用户故事还是人员配合的问题，就是怎么把需求澄清、如何进行产品设计。
1.用户故事卡片可以作为讨论议题，把谁、干什么、为什么写上就好，讨论清楚后产品经理把讨论结果加以补充记录，以备后续查看。
【怎样对一个产品编写完整的用户故事】 2.用例也可以作为讨论议题，区别在于其中增加了很多产品设计细节，一方面帮助技术同事理解需求，另一方面也限制了技术人员需求实现方案的设计，这就要看（1）技术人员与产品人员分工，产品人员只负责收集用户需求还是同时也需要完成一定的产品设计 （2）技术人员的能力和对业务逻辑的理解程度。

■网友
搜索不是一个故事，但是很多人会在用搜索的时候发生很多故事，把他们捕捉，抽象，放大，你的故事就有了。N年前雅虎搜索不是请三位国师拍过三段广告吗？翻出来瞧瞧吧，自行搜索：雅虎搜索广告大片


推荐阅读


上一篇：『交通』交通违法“曝光台”闯红灯

下一篇：大数据在保险业中可能会有那些应用?