研发需求的验收标准应该怎么写?

用户故事要经过 DoR 的考验才能被研发团队接受,只有扛住 DoD 的考核才能迈出走向客户第一步。在敏捷开发中,想要评估一个故事是否达到客户对需求的期待,就要让它去接受「验收标准」的考验:用户故事必须「通过」所有的验收标准,才算是真正地产生价值

在这里插入图片描述

DoD 是对迭代中「所有」工作事项或用户故事的「基本要求」,而验收标准则是对「特定」用户故事的「需求细节」进行的逐一验证。

一个工作项目是否能如质如期地完成,最重要的部分就取决于开工前是否有明确的「验收标准」。

一、 验收标准的目的


01 描述明确的需求范围

通过对验收标准的讨论,团队可以了解产品负责人与利益关系人对需求的期待,也能更明确地掌握需求的范围,方便估计时程与测试涵盖范围。

02 描述错误的案例处理

编写验收标准条例可以全方位地考虑需求可能会出现的限制与错误情况,并延伸对应的处理方式。在开发过程中,实现快乐路径(Happy Path)相对简单,但「错误/例外处理」却常常被遗漏掉。

03 增加共识的讨论模式

透过对验收标准的讨论,产品负责人和开发团队能够一次又一次地理解需求目的,确保对需求持有相同的理解,才能在最后的展示阶段完整地呈现结果。

04 提早列举出测试案

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值