敏捷实践
完成的定义
阅读:
完成的定义
它完成了,是完成的,还是完成完成?
如果您在应用程序开发业务中,您以前亚博vip9通道询问过这个问题。那么完成的定义是什么?在询问问题时,重要的是要注意您在组织中的级别和您的水平。交付团队,计划团队和投资组合团队定义不同的方式。我们肯定知道的是,我们需要在组织各级完成的明确定义。
完成的定义
完成的定义(DOD)是所有条件或验收标准,软件产品必须满足并准备好用户,客户,团队或消费系统接受。我们必须符合完成的定义,以确保质量。通过防止用户故事不符合升级到更高级别环境的用户故事,它会降低返工。它将阻止不符合发送给客户或用户的定义的功能。
用户故事
国防部最常见的使用是交付团队层面。在此级别完成意味着产品所有者审查并接受了用户故事。一旦被接受,“完成”用户故事将有助于团队速度。您必须符合所有已定义的标准或用户故事未完成。
用户故事DOD示例:
- 单位测试通过了
- 代码审查了
- 达到验收标准
- 功能测试通过
- 满足非功能性要求
- 产品所有者接受用户故事
特征
在此级别完成可能意味着它有资格添加到版本。并非所有用户故事都需要完成。相反,它意味着该特征可以足以满足需求。一旦被接受,就会有助于释放速度。同样,您必须符合所有已定义的标准或未完成该功能。
特色国防部示例:
- 达到验收标准
- 集成到干净的构建中
- 晋升为更高的环境
- 自动回归测试通过
- 特征级功能测试通过
- 满足非功能性要求
- 符合合规要求
- 在必要的用户用户文档中记录的功能
史诗
在此级别完成可能是指组织战略优先级,投资组合计划项目,或满足市场需求的其他一些功能。并非所有用户故事或功能都需要完成。相反,史诗可能足以满足需求。一旦被接受,DONE epic将有助于吞吐量计算,以了解供应是否与需求平衡。
epic dod例子:
- 满足非功能性要求
- 结束于结束集成完成
- 回归测试通过
- 促进生产环境
- 符合定义的市场预期
概括
就像这一点一样准备的定义超级重要,所以完成的定义是。在您同意定义之前,永远不要开始工作。始终如一。清楚。有共同的理解。
评论(10)
Amit J Bhattacharyya.
在国防部致谢德里克这种整洁而清脆的汇编。
我刚从经验中看到了一些用户故事国防部和国防部的次数真正重叠或在现实生活中吻合。
我完全欣赏这里的隔离,并同意国防部的最后2个点是非常独家的。但是,在用户故事或故事的Scrum生命周期中,如果“自动回归测试通过”,那么QA团队将无法批准并提出反对它的问题,然后无法进入产品所有者和其他利益攸关方为完成评估本身。
我所看到的另一个是用户故事国防部所需品的一部分是“融入干净的构建”。没有那个,开发团队将无法通过障碍证明交付的故事真的可释放,然后又伤害了赚取可信度的努力。
很想知道你的想法,是的,是的:)我将在Twitter上分享这个好帖子。
Zeeshan Siddiqui
在国防部中包含'不打开临界/高严重程度缺陷'吗?
绝对,我同意它应该。我没有特别称为它,但我相信应该是基本验收标准的一部分。质量应该是核心考虑因素。
Faaz Ahmad Khan.
当我们在国防部添加“通过”或“传递的功能级功能测试”或“功能级功能测试”时,它并非隐含强制执行“No Open Pression / High Severity缺陷”?
大卫墨菲
它确实如此,但有时候值得明确。
Gayathri nimmakayala.
你认为国防部应该如何精心制作?有可能最终看起来像待办事项列表。我们在哪里画线 ?
大卫墨菲
对我来说,国防部应该是10个项目的最大值,可能更像是7.超过那么人们不会打扰或者会失去遗嘱。
paramjit aujla.
亲爱的德里克,
首先,感谢您精心制作的文章。
我会分享我对释放的所有功能进行回归和uat的练习经验。这确保在零售面向零件的应用中没有任何内容。
问候
PARAMJIT.
s
我们是否需要分别定义每个用户故事中的国防部或DOR?我目前正在留下深刻的印象,即DOR或DOD都不需要作为声明写作,而是在团队内部的协议。在一些组织中,我以前工作过的任务是将国防部和DOR写在用户故事中的声明。先感谢您。
内夫哈维
为什么您对用户故事,功能和史诗所做的单独定义?