敏捷DoD完成定义的多种形态
2014-10-05 09:07
211 查看
作者:张克强 作者微博:张克强-敏捷307
关于Definition of Done 完成的定义在以往的说法中,常见用 退出标准 , 完成条件,成功标准,等等在敏捷软件开发中,存在多级的不同的完成定义。典型的是迭代的DoD,这也是最初DoD应用的地方。常见在Scrum中,需要预先定义DoD,常见的迭代DoD条款有:1,所有完成的用户故事得到PO的验证2,所有代码得到静态分析,纠正最高级别的不符合项,静态分析的规则参见...3,所有新增代码得到人工评审4,所有完成的用户故事都有对应的测试用例
而对于发布,一般就有更加严格的要求,发布DoD的典型条款有:1,完成发布规划所要求的重点内容2,通过发布的全量测试,回归测试范围是全范围,回归比率不低于50%3,修复所有等级为1、2、3的缺陷,4级及4级以下缺陷不超过200个。1、2级缺陷必须修复,3级缺陷经过带缺陷发布审批后可以发布。
由于发布需要达到比迭代更高的要求,所以一般很难强制规定发布测试所需要的时间长度,也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上,因为高质量发布是第1要务,如果到了原计划测试结束的时间,仍然留有妨碍发布的缺陷的话,应当修复后才能发布。而迭代成果一般是为了内部或者可控范围内的展示,相对发布而言,要求较低,所以适用时间箱方法,当然迭代本身就是时间箱,迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处,在这样的安排下,回归覆盖率就应当是一个变量,用于观察,而不应当是一个要求指标。
为了更好的达成迭代DoD,就需要提前注意,所以有些更加细节的DoD得到识别并使用。最典型的是每日DoD,典型条款有:1,搭建每日构建环境,晚上自动静态代码检查、编译、部署和测试,每日修复前一日构建和测试发现的缺陷和问题。2,下班前必须检入当天书写的代码3,当天的代码必须在当天或者第2天邀请同伴进行代码评审4,搭建持续集成环境,当天上下午必须至少各检入代码一次(这与第1条可能冲突)5,采用TDD,凡是检入的功能代码必须要有对应的单元测试(严格采用TDD)
还有针对用户故事(或者用例)的DoD,比如1,用户故事最终的描述符合INVEST2,用户故事得到测试用例的对应覆盖3,用户故事得到对应的自动化测试用例4,用户故事得到用户代表试用并初步认可
有少数组织考虑到测试集过于庞大,无法在1天之内测试完成,开展每周全量回归自动化测试,这样就有每周DoD,典型条款有:1,上上周发现的缺陷是否解决2,上周新增功能的自动化测试是否加入到每周测试集。
关于Definition of Done 完成的定义在以往的说法中,常见用 退出标准 , 完成条件,成功标准,等等在敏捷软件开发中,存在多级的不同的完成定义。典型的是迭代的DoD,这也是最初DoD应用的地方。常见在Scrum中,需要预先定义DoD,常见的迭代DoD条款有:1,所有完成的用户故事得到PO的验证2,所有代码得到静态分析,纠正最高级别的不符合项,静态分析的规则参见...3,所有新增代码得到人工评审4,所有完成的用户故事都有对应的测试用例
而对于发布,一般就有更加严格的要求,发布DoD的典型条款有:1,完成发布规划所要求的重点内容2,通过发布的全量测试,回归测试范围是全范围,回归比率不低于50%3,修复所有等级为1、2、3的缺陷,4级及4级以下缺陷不超过200个。1、2级缺陷必须修复,3级缺陷经过带缺陷发布审批后可以发布。
由于发布需要达到比迭代更高的要求,所以一般很难强制规定发布测试所需要的时间长度,也就是说敏捷中常用的时间箱方法不适宜用在发布前的测试上,因为高质量发布是第1要务,如果到了原计划测试结束的时间,仍然留有妨碍发布的缺陷的话,应当修复后才能发布。而迭代成果一般是为了内部或者可控范围内的展示,相对发布而言,要求较低,所以适用时间箱方法,当然迭代本身就是时间箱,迭代内的测试本来就有时间限制。采用时间箱来安排迭代内的测试可以获得时间箱安排的种种好处,在这样的安排下,回归覆盖率就应当是一个变量,用于观察,而不应当是一个要求指标。
为了更好的达成迭代DoD,就需要提前注意,所以有些更加细节的DoD得到识别并使用。最典型的是每日DoD,典型条款有:1,搭建每日构建环境,晚上自动静态代码检查、编译、部署和测试,每日修复前一日构建和测试发现的缺陷和问题。2,下班前必须检入当天书写的代码3,当天的代码必须在当天或者第2天邀请同伴进行代码评审4,搭建持续集成环境,当天上下午必须至少各检入代码一次(这与第1条可能冲突)5,采用TDD,凡是检入的功能代码必须要有对应的单元测试(严格采用TDD)
还有针对用户故事(或者用例)的DoD,比如1,用户故事最终的描述符合INVEST2,用户故事得到测试用例的对应覆盖3,用户故事得到对应的自动化测试用例4,用户故事得到用户代表试用并初步认可
有少数组织考虑到测试集过于庞大,无法在1天之内测试完成,开展每周全量回归自动化测试,这样就有每周DoD,典型条款有:1,上上周发现的缺陷是否解决2,上周新增功能的自动化测试是否加入到每周测试集。
相关文章推荐
- 敏捷DoD完毕定义的多种形态
- 【敏捷开发每日一贴】DoD“完成”的定义
- 神马是敏捷?(1)——敏捷的“官方”定义
- YAML 简介----试图用一种比 XML 更敏捷的方式,来完成 XML 所完成的任务
- Google完成VP9视频编码格式定义
- 它们的定义PropertyPlaceHolder无法完成更换任务
- struct多种声明定义写法的小结
- Web上功能强大的DbGrid表格HTC组件[只需在Table中指定样式就可以完成多种功能可扩展]
- Unreal Engin_画廊制作笔记 _002<利用简单的网格模型完成场景基本形态>
- JS 多种变量定义
- Spring进阶教程之在ApplicationContext初始化完成后重定义Bean
- 软件开发模式定义、区别(瀑布、迭代、螺旋、敏捷)
- 数据库多种范式的定义 3NF BCNF
- Arcgis js featureLayer加载完成之后,对其加载的要素重新定义样式
- java定义object数组(可以存储String或int等多种类型)
- 浅谈js函数的多种定义方法与区别
- JavaScript函数的多种定义方法
- netty+protobuf使用netty自带编解码器完成多种协议格式分发
- TIP1. struct多种声明定义写法的小结
- 基于netty的项目中使用protobuf,巧妙定义proto完成不同消息的编码和解码处理