什么是用户故事，用户故事的要素及需求分析？-营销圈

什么是用户故事，用户故事的要素及需求分析？

用户投稿 • 2022年6月8日 pm5:14 • 网络资讯 • 阅读 335

Kanban及Scrum的敏捷开发方法论无法解决需求敏捷化；但是「用户故事」能很好地解决

一个好的用户故事包括三个要素：

什么是用户故事，用户故事的要素及需求分析？

「Card 卡片」用户故事通常写在故事贴/卡片上；可能写上故事的简短描述/工作量估算等

「Conversation 交谈」用户故事的细节来源于与客户或者产品负责人的交流沟通

「Confirmation 确认」通过验收测试用例，验收「用户故事」被确认完成

「Construction构建」团队通过技术手段实现这个用户故事的功能或要求

「Consequence 后果」交付给用户真正使用，获得反馈

Sprint计划会议里，有一个很重要的技术环节「故事点的估计」：对要开发的用户故事进行一个粗量级的估算，对用户故事的复杂度有一个具体的了解

传统软件团队通常用工时估算工作量：工时是一种绝对估算的方式；它的估算方法，通常依赖于历史经验信息；对流程较为固定，需求较为稳定的团队来说，工时估算方法是适合，但是工时估算难以应对客户需求的频繁变更，
敏捷估算方法是相对估算的概念，没有绝对的估算天数和小时数；故事点是敏捷开发过程中，常用的一种相对估值方式：针对不同需求，可以估算一个需求比另一个需求更大，大多少倍；但是不确定每个需求的准确工作量；一旦对某个故事点的相对规模达成共识，就可以快速分配，而无需太多辩论故事点让团队基于难度而非时间来解决问题，这使得团队成员更关注于创造价值；而不是专注于花了多少时间
故事点估算软件规模可以使用近似斐波那契数列: 「0，1⁄2，2，3，5，8，13」 或 T-恤尺码： 「XS，S，M，L，XKL 」来估算；帮助团队围绕工作规模，做出更好的决策

【Tips：实际工作中，工时或故事点规模估算没有优劣之分；只有适不适合；总而言之，良好的估算实践 1⃣️有助于团队掌握项目的成本和盈利能力 2⃣️还有助于团队对于要交付的需求规模，优先级，价值达成共识；从而更好的做出业务决策」

用户角色：不仅是人的岗位，角色，还包括周边系统
业务流程：用户与被实现系统之间的交互流程；但不包括系统内部各部件之间的交互流程（各系统之间的交互还有数据库等，在用户故事里面是感知不了的；在实现用户故事时，如果有涉及到系统之间的交互，也要想好要什么样的旅程「用户故事地图」：点击跳转新的，还是直接打开页面。而且作为产品，有时候有监控数据需求时，还需要明确哪些信息怎么存，或者存不存）
提取用户故事：根据用户故事可以感知的层次，从交互步骤中提取出一个个的用户故事
整理用户故事：如果用户故事太大，则需要进一步分割；如果用户故事太小，则可以跟其他用户故事合并

用户故事典型步骤

用户故事地图

「Independent 独立性」一个用户故事尽可能独立于另一个用户故事；用户故事之间的依赖性使得确定计划，确定优先级，工作量估算变得很困难；通常会通过组合用户故事或者分解用户故事，减少用户故事得依赖性
「Negotiable 可协商」一个用户故事得内容，要是可协商得；用户故事不是合同，只是对需求的一个简短描述；不包括太多细节；具体的细节在沟通阶段产出，如果一个用户故事带有太多的细节；实际上它限制了和用户的沟通
「Valuable 有价值的」 每一个用户故事必须对客户有价值；一个让用户故事有价值的好方法是让客户写下它们；让用户意识到这是一个用户故事，而不是一个契约；而且在可以协商的时候，他们是乐于写下用户故事的
「Estimable 可估算的」 开发团队需要去估算，以便确定优先级，工作量，和安排计划
「Small 短小」 一个好的用户故事，尽量短小，最好不要超过10个人日的工作量；至少要确保能在一个Sprint里完成；因为用户故事越大，安排计划工作量的风险也就越大
「Testable 可测试性」一个用户故事要是可测试的，以便于确认是可以被完成的；如果不能被测试，那就无法知道它什么时候可以完成【Tips：用户故事也是测试/验收驱动开发的实践』

好了，这篇文章的内容营销圈就和大家分享到这里，如果大家网络推广引流创业感兴趣，可以添加微信：Sum8338 备注：营销圈引流学习，我拉你进直播课程学习群，每周135晚上都是有实战干货的推广引流技术课程免费分享！

好了，这篇文章的内容营销圈就和大家分享到这里，如果大家对网络推广引流和网络创业项目感兴趣，可以添加微信：Sum8338 备注：营销圈引流学习，我拉你进直播课程学习群，每周135晚上都是有实战的推广引流技术和网络创业项目课程分享，当然是免费学！

什么是用户故事，用户故事的要素及需求分析？