项目中所说的故事点是什么意思?

本文讲述了故事点估算方法,一种通过分配相对数值衡量产品待办项工作量的工具,强调了考虑工作数量、复杂度、风险和不确定性等因素的重要性。

故事点,是一个度量单位,用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。
配图理解

当采用故事点估算时,我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要,我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。

团队避免采用100、200、300,或者1百万、2百万、3百万,而要使用1、2、3。估算结果是比值,而不是绝对值。

故事点包括什么内容呢?
画一下方便理解

由于故事点数代表了开发用户发故事所需的全部工作量,所以团队的估算必须考虑到影响工作量的所有因素。这可能包括:

要开展的工作的数量、工作的复杂度、要开展的工作中存在的任何风险或不确定性。

在用故事点估算时,必须要考虑以上每一个因素。让我们看看每个因素是如何影响故事点的:

要开展的工作数量(The Amount of Work)

如果要开展的工作越多,工作量的估算值当然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个只需要输入一小段文本的字段。

第二个网页并不比第一个网友更复杂。字段之间是不存在交互的,每个字段只不过是一点文本而已。因此第二个网页并不存在额外的风险。这两网页之间的唯一区别就是第二页有更多的事情要做。

应该给予第二个网页更多的故事点数。但它即使有多了100倍的字段数,可能仍然得不到多100倍的点数。毕竟,由于规模经济效应,第二个网页的工作量可能只是第一个网页的工作量的2或3或10倍。
举例说明

风险和不确定性(Risk and Uncertainty)

产品待办项的风险和不确定性会影响其故事点估算值。

如果产品待办项的干系人在询问需求事说得不清不楚,那么团队在估算时应当把不确定性也反映在估算结果中。

如果要实现一项功能时需要改动一段缺乏自动化测试的、结构脆弱的老代码,那么估算结果中也应该反映这个风险。
举例说明

复杂度(Complexity)
资料

在进行故事点估算时,还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。

现在考虑另一个也有100个字段的网页。但这些字段中,有些是采用日历控件弹出的日期字段;有些是格式化的文本字段,如电话号码或社会安全号码;另一些字段则需要做信用卡号码的校验和验证。

页面上的字段之间还需要相互交互。如果用户输入一个VISA卡,会显示三位CVV字段。但是如果用户输入美国运通卡,则需要显示四位CVV字段。

尽管这个页面上仍然只有100个字段,但这些字段更难实现。它们更复杂,需要花更多时间才能实现。开发人员出错的可能性更大,因此不得不采取一些预防和纠正措施。

这种额外的复杂度都应该反映在所提供的估算结果中。

要考虑所有因素:工作数量、风险和不确定性,和复杂度

把这三个因素合成一个数字并提供一个估算值,貌似是不可能的。然而其实是可能的,因为可以统一到工作量这个因素。

首先,估算人员要考虑的是:完成产品待办项所描述的那些工作,到底需要多少工作量。

然后,估算人员要考虑的是:在处理产品待办项的风险和不确定性方面需要付出多少工作量。通常可以通过考虑到问题发生的风险以及风险确实发生会造成的影响来做到。因此,例如,一个可能会发生并将消耗时间的风险将会增加估算值,而一个不太可能发生且无关紧要的风险则不会增加估算值。

此外,估算人员还要考虑要开展的工作的复杂度。复杂的工作需要花费更多的心思,可能需要进行更多的试错试验,可能需要与客户进行更多的反复,还可能需要花费更长的时间来验证和改正错误。

所有这三个因素必须都结合考虑。

要考虑“完成的定义”中的要求

故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事(并且这是一个好主意)这个事项,那么创建这些测试的工作量也应该包含在故事点估算结果中。

故事点可能是个难以把握的概念。但是花时间去充分理解——故事点数代表着其工作的数量、复杂度、其风险和不确定性以及时间。
配图理解

<think>嗯,用户这次的问题是关于敏捷开发中如何拆分长篇故事(史诗故事)为用户故事。从提供的引用材料来看,用户已经对用户故事的基本概念和层次有了一定了解,但需要具体的拆分方法论。 用户可能正在参与敏捷项目,遇到了需求管理混乱的问题。ta的深层需求可能是想掌握系统化的拆分技巧,而不仅仅是理论概念。从引用[5]提到的“需求是用户维度,任务是开发维度”能看出,用户特别关注如何保持拆分后的故事仍具备业务价值。 引用[2]提到用户故事处于敏捷需求的中间位置,这提示我需要强调拆分是自上而下的过程。而引用[4]给出的标准格式“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”是很好的检验工具。 最实用的应该是引用[1]指出的痛:大小不一的故事堆积会导致功能可视性差。这明拆分需要遵循某些粒度标准。结合Scrum实践,我想到几个关键维度:用户角色(引用[4])、业务流程(引用[2])、价值交付(引用[1])。 用户可能没意识到但需要知道的是:故事拆分深度会影响冲刺规划。引用[5]区分需求与任务的观很重要,要避免把技术任务当作用户故事。比如“重构数据库”是任务,而“用户能3秒内加载报表”才是故事。 值得补充的是INVEST原则,虽然引用里没提,但能解决用户对“合理粒度”的困惑。特别是“可协商”对应引用[3]的思维层转型——拆分时要保留调整空间。 最后用引用[2]的用户故事地图概念设计回答框架:先确定用户旅程主干,再分解关键活动,最后细化到原子操作。这样既系统化又避免碎片化,正好解决引用[1]的堆积问题。</think>在敏捷开发中,将长篇故事(史诗故事)拆分为用户故事需要遵循**价值导向、独立交付、可测试性**三大原则,并结合分层拆解策略。以下是具体拆分方法及示例: --- ### 一、分层拆解框架(5层模型) ```mermaid graph TD A[史诗故事] --> B[特性] B --> C[用户故事] C --> D[任务] ``` 1. **史诗故事(Epic)** 描述完整业务目标,如“构建电商支付系统”[^2][^5]。 *粒度:跨多个迭代,无法直接交付* 2. **特性(Feature)** 实现史诗的关键能力,如“支持信用卡支付”[^2]。 *粒度:1-2个迭代交付* 3. **用户故事(User Story)** 独立交付用户价值的原子单元,需符合**INVEST原则**[^4]: - **I**ndependent(独立) - **N**egotiable(可协商) - **V**aluable(有价值) - **E**stimable(可估算) - **S**mall(足够小) - **T**estable(可测试) *示例:作为买家,我想绑定Visa卡,以便快速支付订单[^4]* 4. **任务(Task)** 开发人员执行的技术动作,如“开发信用卡绑卡API接口”[^5]。 --- ### 二、4种核心拆分方法 #### 1. 按用户旅程拆分 ```mermaid journey title 支付流程 section 选择支付方式 --> 输入卡信息 --> 安全验证 --> 支付成功 ``` - 故事1:作为买家,我能选择信用卡支付方式 - 故事2:作为买家,我能输入卡号/有效期/CVV - 故事3:作为买家,我能通过3D Secure验证身份[^4] #### 2. 按业务规则拆分 *规则:不同卡类型有不同验证逻辑* - 故事1:验证Visa卡(16位卡号,CVV3位) - 故事2:验证Amex卡(15位卡号,CVV4位) - 故事3:验证银联卡(19位卡号)[^1] #### 3. 按数据边界拆分 *支付涉及的数据实体:* - 故事1:存储信用卡信息(卡号/持卡人/有效期) - 故事2:记录支付交易流水(金额/时间/状态) - 故事3:管理支付风控规则(单笔限额/日限额)[^5] #### 4. 按技术实现拆分 *示例:支付成功通知* - 故事1:支付成功后发送站内信通知 - 故事2:支付成功后发送短信通知 - 故事3:支付成功后推送APP消息[^2] --- ### 三、拆分质量检验标准(INVEST原则) | 原则 | 检验问题 | 反例(不合格故事) | |--------------|----------------------------------|--------------------------------| | **独立** | 是否不依赖其他故事? | “修改信用卡绑卡页面”需依赖“绑卡功能” | | **有价值** | 用户能否直接感知价值? | “重构支付代码”(无用户价值) | | **足够小** | 能否在1个冲刺内完成? | “重建整个支付系统”(过大) | | **可测试** | 能否写出验收条件? | “提升支付体验”(无法验证) | > ✅ 合格故事示例: > *作为国际买家,我能用PayPal支付订单,以便使用境外账户[^4]* > **验收条件**: > 1. 支付方式选择页显示PayPal图标 > 2. 击后跳转PayPal授权页面 > 3. 授权成功后返回订单支付成功页 --- ### 四、用户故事地图实践 通过横向(用户流程)和纵向(优先级)组织故事: ```mermaid flowchart LR A[支付方式] --> B[信用卡] A --> C[PayPal] A --> D[银行转账] B --> B1[绑卡] B --> B2[支付] B1 --> B1a[输入卡信息] B1 --> B1b[3D验证] ``` **优先级排序**: 1. 核心流程(信用卡支付) 2. 扩展流程(PayPal/银行转账) 3. 增强功能(支付优惠/分期)[^2] --- ### 关键总结 1. **价值驱动**:每个故事必须对应明确的用户目标(“以便...”子句)[^4] 2. **原子化**:拆分到可独立开发/测试/部署的粒度(约2-5人天) 3. **动态调整**:在冲刺规划会上与PO确认拆分合理性[^3] > ⚠️ 避免陷阱: > - 技术任务冒充用户故事(如“创建支付数据库表”) > - 过度拆分丧失业务上下文(如“设计输入框”脱离支付场景)[^1][^5]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值